Move auto-publish workflow to publish on demand workflow

[zplata]

Currently

On every merge to master, we auto-publish a bumped patch version on all our web runtime NPM packages (@rive-app /canvas, /canvas-advanced, /canvas-single, /canvas-advanced-single, /webgl, /webgl-advanced, /webgl-single, /webgl-advanced-single) using a combination of shell/node scripts. While this technically works, we should really consider moving to a model similar to other Rive runtimes where we publish on demand by manually triggering a Github Workflow that lets us determine to publish/release a patch, minor, or major version. This would allow us to publish on our own terms, and prevent releases we don't really need (i.e docs updates). And allow us to really do major/minor semver releases without manual intervention.

Proposal

With this proposed PR and model, we use the release-it tool to coordinate package.json bumps, running scripts at the appropriate time, creating Git tags, npm publishes, committing and pushing back to master, and eventually, auto-generating CHANGELOG.md blocks. This is currently used in the React, iOS, and Android runtimes.

Idea:

1. User triggers a publish Github Action workflow dispatch, choosing either major, minor, or patch (default) bump
2. release-it bumps the main package.json version in /js accordingly
3. Run a series of scripts after this bump in /js/.release-it.json in the after:version:bump hook:
   • Copy the new version to all web runtime package variants' package.json files version property (npm run copyVersions)
   • Run the /js/build.sh script to build all the JS/WASM/types for the runtimes (npm run build:all). Build relies on the package.json version for each runtime having been bumped already, so this is why we place the build script at this specific point in the release-it workflow
   • Run tests (npm test)
   • Run publish script to publish all npm packages (npm run publish:all) to NPM registry
4. release-it continues its process to add a new Git tag with the new version, commits all untracked files (which should just be the updated package.json files for each npm package), and commits/pushes the changes and tag to remote

Notes

We don't do a formal Github Release as there's no releasable software to include here (it's available in the distribution via NPM registry) and because we have multiple variants/npm packages of the web runtime, it might be confusing what we include here. A Github Tag might suffice here.

Adding CHANGELOG updates in a subsequent release. We would use the auto-changelog plugin for release-it, as recommended, to add to a CHANGELOG. But because we have no previous tags really, adding the CHANGELOG to this would include every commit over the past 1.5 years, which seems excessive to display for one release and which isn't true. So we can specify to start this CHANGELOG after the first Github Tag release here. Couldn't find a better way to parse out the old stuff here and just include newer commits in the CHANGELOG, so just going with this approach.

Also, not all variants of the web runtime (i.e. @rive-app/canvas and @rive-app/webgl) are on the same version. This aligns it all to use the same version.

We don't actually npm publish anything from the main js/package.json, or use release-it to do the actual registry publish. It's mainly meant for tracking the "source-of-truth" version all the other npm package.json's should use and for running other development/build scripts. You'll note that the js/.release-it.json config shows publish: false under npm config to reflect this.

[zplata]

LGTM! Sort of a rubber stamp since I haven't followed this runtime flows too much, but the description and the code both look sensible. I guess we're moving away from any type of automated release on JS..?

@umberto-sonnino yep! Probably an interim step right now just to make it consistent across at least the mobile runtimes. Right now it's kind of a funky script that's just automating patch version bumps all around. So this also allows us flexibility to more easily dictate minor/major bumps.