v2 is a local-first rich-text editor with versioning capabilities.
Built on top of Automerge, ProseMirror and integrated with the Pandoc ecosystem.
- Package manager: pnpm
- Node (version listed on
.nvmrc) - Git LFS (needed for WASM files)
- Commit style: Conventional commits
$ pnpm install$ git lfs pull$ pnpm run devIt is possible to attach breakpoints to the main process code in VSCode if you do the following:
- Run
pnpm run debugfrom your OS terminal (outside VSCode) - Manually attach the VSCode debugger via the VSCode UI
Don't forget to close the debugger in the end of your session.
Note: There is an issue that seems to be related to EffectTS runtime when you start the app from the VSCode integrated terminal (we get Effect-related errors we don't get when we run it from the OS terminal).
Storybook is used to build and render components in isolation.
To start Storybook, run:
pnpm run storybookTo build v2 in production mode, run:
pnpm run buildThis will build the app under the dist directory. To run the built production version:
pnpm run startv2 leverages Semantic Versioning as part of its Continuous Integration stategy.
Semantic version, in a nutshell, is the vMAJOR.MINOR.PATCH (f.e. v0.1.1) found in most applications and websites nowadays, where
- MAJOR version when you make incompatible API changes
- MINOR version when you add functionality in a backward compatible manner
- PATCH version when you make backward compatible bug fixes
Additionally, pre-release tags indicate alpha or beta software versions (as v0.2.0-alpha or v5.9-beta.3.)
There is a release workflow available in GitHub CI, which:
- Creates a tag and a version bump commit
- Builds the app and creates executables for various operating systems
- Creates a new draft release with the executables as artifacts
If for any case the release workflow fails, the version bump and the commit are reverted automatically (in a conditional cleanup step of the worfklow itself).
By default, the release worfklow performs a patch update from the previous version (v0.1.1 → v0.1.2), but this default is an option for the maintainer who runs the release worfklow. You can override this by including one of the following in the commit message: #major, #minor, or #patch. For details, see bumping in github-tag-action.
After the draft release is created, you can review and edit the release notes, then publish the release on GitHub.
macOS
Code signing and notarization are performed during the build process. No separate publish step is required.
Required secrets: CSC_LINK, CSC_KEY_PASSWORD, APPLE_ID, APPLE_TEAM_ID, APPLE_APP_SPECIFIC_PASSWORD
Arch Linux
When a release is published, a separate Publish Packages workflow automatically triggers and publishes to AUR (Arch User Repository):
- Generates a PKGBUILD file for the new version
- Commits the PKGBUILD to the separate AUR package repository (
v2-binon aur.archlinux.org) - This is independent from the main source code repository
Required secrets: AUR_USERNAME, AUR_EMAIL, AUR_SSH_PRIVATE_KEY
Ubuntu/Debian
When a release is published, the Publish Packages workflow also publishes to a custom APT repository:
- Downloads the
.debpackages (amd64 and arm64) from the GitHub release - Generates APT repository metadata (Packages, Release files)
- Signs the repository with GPG
- Commits to the separate
v2-debrepository hosted on GitHub Pages
This allows Ubuntu/Debian users to install and update v2 via apt. See oktana-coop/v2-deb for installation instructions.
Required secrets: APT_GPG_PRIVATE_KEY, APT_GPG_KEY_ID, GH_PAT
To create artifacts for various operating systems, first build the app as shown above. Then run:
pnpm run packageThis will produce the artifacts in the bin directory.
If you need to debug the produced artifacts, you can run:
pnpm run app:dirTo extract and inspect the asar file contents (example for Linux build), in a directory named test:
pnpx @electron/asar extract bin/linux-unpacked/resources/app.asar test