Release

How a version of EDGEwave goes out: to the VS Code Marketplace and Open VSX by the Publish workflow, run by hand from the Actions tab as REDnode’s Release workflow is, and to Nexus Mods by hand. The first release is 0.1.0, as a preview ("preview": true in package.json).

What ships

The .vsix is one file for every platform: EDGEwave has no native parts and no runtime dependencies. It holds the two bundles in dist/ (minified, no source maps: node esbuild.mjs --production, vsce’s prepublish), media/editor.css, the icons, the Marketplace README (README.marketplace.md, through --readme-path), the CHANGELOG and the LICENSE; .vscodeignore leaves out the rest. The repo’s own README.md stays the GitHub page.

Steps

1. Tests. Every phase in the release has passed its hand test (Tests); npm run typecheck, npm test and npm run smoke pass.
2. Version. Set version in package.json (and npm install, so package-lock.json follows). In CHANGELOG.md, rename Unreleased to ## <version> (<date>) and start a new empty Unreleased above it: the workflow fails without the version’s section, and puts it in the GitHub release (npm run release:notes prints what it will say).
3. Package and test the package.

   npm run package      # edgewave-<version>.vsix in the repo folder
   npm run vsix-test    # a clean VS Code: installs it, and REDcode from the Marketplace; opens, renders, Add to Project
   npm run nexus-zip    # dist/EDGEwave-<version>-nexus.zip
   npm run rednode-zip  # dist/edgewave-voice-<version>.zip, EDGEwave Voice for REDnode (its version is in rednode/edgewave-voice/rednode-app.json)
   

4. Commit and push to main.
5. Publish (the owner): Actions > Publish > Run workflow on main.
   • Unticked, it checks, tests and packages, and keeps the .vsix and the Nexus zip as the run’s artifact. Nothing is published: a dry run.
   • With Make a release ticked, it also publishes to the Marketplace and Open VSX and makes the GitHub release v<version>, which tags the commit. It stops first if that tag exists (raise the version) or CHANGELOG.md has no section for the version.
   • With Update Nexus Mods ticked too, it first checks the Nexus page (nexus.mjs check), before anything is published, and stops if the description changed on Nexus since the last pull. After the GitHub release it uploads the Nexus zip as the main file’s new version (the old one archived), EDGEwave Voice’s zip when its version is new (its own version, in rednode/edgewave-voice/rednode-app.json), adds the version’s changelog (release:notes --nexus), and pushes nexus/description.bbcode when it differs.
6. Nexus, before the run: npm run nexus:status on the dev PC (the key in %APPDATA%\Edgemodders\nexus-key.txt, see tools/nexus/api.mjs). If the description changed on Nexus, npm run nexus:pull, merge the repo’s changes back in (git diff nexus/), and commit. node tools/nexus/nexus.mjs check --version <v> --file voice=<voice version> says what the release will do. If the Nexus step fails after the other stores, run node tools/nexus/nexus.mjs release on the dev PC with the workflow’s arguments.
7. After: the README’s and the Nexus page’s status, and docs/ where a page says what is released.

The packaged test

tools/vsix-test.mjs (npm run vsix-test) checks the .vsix as a modder gets it, in a clean VS Code profile (the VS Code the smoke test downloaded):

It needs the network (the Marketplace). Found while writing it: a .edgewave passed on the command line to a brand-new profile opens as JSON text, since VS Code opens it before it has read the extensions’ editors; opened from the Explorer, Quick Open, the Sounds view or REDcode, it gets the EDGEwave editor.

Releases