chore(ci): add NPM auto-publish workflow

[PaulHax]

NPM Auto-Publishing

Tag-based approach that avoids committing version bumps to main.

Flow

1. Merge to main → bump-version.yml creates version tag (v4.4.1, v4.4.2, etc.)
2. New tag → publish-npm.yml publishes to NPM

For minor/major releases, manually create tags:

git tag v4.5.0
git push origin v4.5.0

Setup done for OIDC trusted publishing on npmjs.com

closes #814

[netlify]

✅ Deploy Preview for volview-dev ready!

Name	Link
🔨 Latest commit	6af3f85
🔍 Latest deploy log	https://app.netlify.com/projects/volview-dev/deploys/690e49f2b050cd000845cde8
😎 Deploy Preview	https://deploy-preview-815--volview-dev.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[zachmullen]

Given all the feat: / chore: and whatnot I would have assumed we would want to use semantic-release, is that not the case?

[PaulHax]

Given all the feat: / chore: and whatnot I would have assumed we would want to use semantic-release, is that not the case?

I'm with ya. Guess we have looked at version number as more marketing. An of course i'm not sure we want to take on ommiting to semantic release promise of no breaking changes without major version bump...

But if you want to drop the semantic release commit message convention I'm listening.

[zachmullen]

If we're not using semantic-release I'd be for dropping the commit message convention, personally, but we should maybe find out who added that convention in the first place and why before we abandon it.

Also, just my personal preference, I don't like semantic-release in general and prefer manually controlling the releases via git tags, but that doesn't auto-publish on every merge to main, so maybe it doesn't meet the needs of what we are trying to do here.

My worry about the approach you wrote here is that it'll end up polluting main branch history with a ton of artificial commits. Is there precedent for this approach in other projects? I haven't seen it done this way before.

[zachmullen]

Another worry I just thought of about this approach is race conditions could occur if multiple branches get merged to main branch close together; there's a critical section between the checkout step and the publish step that's actually a fairly long window.

[PaulHax]

Agree to all of above. If we can though, I would like to auto publish on merge to main as I often forget to "click the button"/"pushed the tag" after merging to release.

Perhaps we can track the version via git tags, have the workflow update the version tag on merge to main, then the workflow edits the package.json with tag version and publishes to NPM. < - This would be a haxed semantic commit apporach and avoid adding another commit. In this case, perhaps we have a second Github workflow that triggrs on new version tags that does the publish, and the merge to main workflow just a patch version tag bump?

I'm guessing Github's merge queue feature which we have on will avoid the race condition.

[zachmullen]

Perhaps we can track the version via git tags, have the workflow update the version tag on merge to main, then the workflow edits the package.json with tag version and publishes to NPM. < - This would be a haxed semantic commit apporach and avoid adding another commit. In this case, perhaps we have a second Github workflow that triggrs on new version tags that does the publish, and the merge to main workflow just a patch version tag bump?

That sounds good to me. This is kind of like how we do it with Python packages, where we publish pre-release versions automatically on merge to main, but a tag push triggers a real release version. npm also supports pre-release version identifiers so we can make use of those.

I'm guessing Github's merge queue feature which we have on will avoid the race condition.

Ok, cool.

[PaulHax]

@zachmullen I took a crack and implimenting tag based version tracking

[zachmullen]

Should we make these prerelease versions with --preid=dev instead of patch versions? That would mean that by default, people installing VolView in their project would get a stable manual release rather than the cutting-edge main branch.

[PaulHax]

Yes. Added another commit for that.

[PaulHax]

superseded by #820