This repository was archived by the owner on Apr 6, 2026. It is now read-only.
ci: use electron/semantic-trusted-release instead of npx#181
Closed
MarshallOfSound wants to merge 1 commit intomainfrom
Closed
ci: use electron/semantic-trusted-release instead of npx#181MarshallOfSound wants to merge 1 commit intomainfrom
MarshallOfSound wants to merge 1 commit intomainfrom
Conversation
Replaces the two-phase npx semantic-release pattern (dry-run → stamp → real run) with a single run using @semantic-release/exec's prepareCmd hook. The prepare step fires after the version is determined but before publish — exactly when version stamping needs to happen. The previous approach used npm install -g semantic-release@22.0.6 followed by npx semantic-release@22.0.6. The npm -g install meant npx resolved the global install rather than fetching from the registry, but the whole thing was still unpinned at the lockfile level and semantic-release-export-data was fetched unpinned. @semantic-release/exec isn't bundled with semantic-release core and isn't in semantic-trusted-release's lockfile, so it's installed locally via package-lock.json. semantic-release resolves plugins from the project's own node_modules. The stamp logic moved to scripts/stamp-version.sh — same cross-stamp-and-verify pattern (x64 stamps x86, verify, x86 stamps x64, verify).
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
erikian
reviewed
Mar 31, 2026
Member
There was a problem hiding this comment.
question: since there's no lockfile to migrate, would it make sense to take the opportunity and have this package use yarn instead of npm?
Member
There was a problem hiding this comment.
question: @semantic-release/commit-analyzer, @semantic-release/release-notes-generator and @semantic-release/github are transitively pulled via whatever version of semantic-release is depended on by @semantic-release/exec, is that setup expected/acceptable or should we explicitly depend on those plugins instead?
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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
3 participants
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.
Replaces the two-phase
npx semantic-releasepattern withelectron/semantic-trusted-release(same as the rest of the org).The old flow:
npm install -g semantic-release@22.0.6 semantic-release-export-data@v1.0.1npx semantic-release@22.0.6 --dry-run→ exports next versionnpx semantic-release@22.0.6→ publishThe
npm -ginstall meant npx resolved the global install rather than fetching fresh, but there was no lockfile —semantic-release@22.0.6resolves to whatever transitive tree npm gives you on the day, andsemantic-release-export-data@v1.0.1came along unpinned.The new flow:
Single semantic-release run.
@semantic-release/exec'sprepareCmdhook fires after the version is determined but before publish — exactly when stamping needs to happen. The cross-stamp-and-verify logic (x64 stamps x86, verify, x86 stamps x64, verify) is unchanged, just moved toscripts/stamp-version.sh.@semantic-release/execisn't bundled with semantic-release core and isn't insemantic-trusted-release's lockfile, so it's installed locally vianpm ci+package-lock.json— semantic-release resolves plugins from the project's ownnode_modules.Also:
persist-credentials: falseon checkoutpull-requests/issueswrite perms for release commentsnode_modules/in .gitignore