fix(npm): read install.js version from package.json#37
Merged
Conversation
The release workflow runs 'npm version $tag' to bump package.json from
the git tag, but install.js had its own hard-coded VERSION = '0.3.0'
constant that nothing was updating. So at release time the package
metadata says (e.g.) 0.4.0 while the postinstall still downloads the
0.3.0 binary archive, silently shipping an older binary to anyone
running 'npm install -g stacklit'.
Reading the version from ./package.json makes that release-time bump
the single source of truth. No new dependency, no extra release step,
and the version stays correct for pre-releases ('0.4.0-beta.1' style)
since goreleaser uses the same scheme for its archive names.
Contributor
There was a problem hiding this comment.
Pull request overview
Note
Copilot was unable to run its full agentic suite in this review.
Fixes npm postinstall downloading the wrong release archive by making npm/install.js derive the version from package.json, matching the version set by the release workflow.
Changes:
- Replace hard-coded
VERSIONinnpm/install.jswithrequire('./package.json').version - Add inline documentation explaining the drift issue and why
package.jsonis the single source of truth
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this fixes
npm/install.jshad a hard-codedVERSION = '0.3.0'constant. Meanwhile the release workflow runsnpm version $tagagainstpackage.jsonat publish time. Sopackage.jsongot the right version on release, butinstall.jskept downloading the 0.3.0 archive — silently shipping an old binary to anyone runningnpm install -g stacklit.Reading the version from
./package.jsonat runtime makes the release-timenpm versionbump the single source of truth. One field, one place to update.Why this matters now
We're about to tag the first release that bundles the
exportcommand (#36) and the Windows install fix (#35). Without this fix, that release would publish[email protected]on npm, but the postinstall would still try to download the v0.3.0 release archive — losing both new features for anyone installing via npm.Test plan
node --check npm/install.jspassescd npm && node -e "console.log(require('./package.json').version)"returns the current versionnpm install -g stacklitpulls the matching tagged archive