refactor(release): isolate semantic-release in .release/ subpackage#35
Merged
Conversation
PR #34 moved semantic-release out of devDependencies to an ephemeral `npm install --no-save --no-package-lock` in the release workflow. That fixed Vulnerabilities 7->10 on OpenSSF Scorecard but dropped Pinned-Dependencies 9->9 (still flagged) because Scorecard counts `npm install` as unpinned; only `npm ci` against a lockfile is accepted as pinned. Move the tooling into a .release/ subpackage with its own package-lock.json. The release workflow now runs `npm ci --prefix .release` and executes the binary from .release/node_modules/.bin/. Why this is the same audit outcome as PR #34 but without the scorecard penalty: `npm audit` only walks the tree rooted at the current directory. With tooling in .release/node_modules/, the root `npm audit` never sees the bundled `npm` CLI or its vendored brace-expansion/picomatch advisories; they are reachable only from `.release/` which we never audit on main. Upstream context: npm/cli#9194 tracks the same advisories (brace-expansion GHSA-f886-m6hf-6m8v, picomatch GHSA-3v7f-55p6-f55p and GHSA-c2c7-rcm5-vvqj). The fix lands in npm 11.13.0 (PR npm/cli#9240). Once @semantic-release/npm picks it up via its `^11.6.2` range, `npm update` inside `.release/` refreshes the lockfile without any other churn.
|
🎉 This PR is included in version 0.6.5 🎉 The release is available on: Your semantic-release bot 📦🚀 |
pavel-kalmykov
added a commit
that referenced
this pull request
Apr 17, 2026
After #35 isolated the release tooling in .release/, Dependabot's security scan walked the new lockfile and tried to create a security update for brace-expansion inside `node_modules/npm/node_modules/`. That path is bundled by the npm CLI tarball and cannot be bumped independently, so the run failed with `unknown_error`. Add a second `npm` entry for /.release with `allow: dependency-type: direct` so Dependabot only considers direct deps (semantic-release, @semantic-release/changelog, @semantic-release/git) there. Transitive advisories inside npm's own bundled node_modules are out of scope for both us and Dependabot; they land upstream via npm/cli releases.
1 task
bitbucket-mcp-bot Bot
pushed a commit
that referenced
this pull request
Apr 17, 2026
## [0.6.6](v0.6.5...v0.6.6) (2026-04-17) ### Bug Fixes * **dependabot:** scope .release to direct dependencies only ([163a21c](163a21c)), closes [#35](#35)
pavel-kalmykov
added a commit
that referenced
this pull request
Apr 17, 2026
PR #34 (ephemeral install) traded Vulnerabilities 7→10 at the cost of Pinned-Dependencies staying at 9 because `npm install --no-save` is flagged as unpinned. PR #35 (.release/ subpackage with its own lockfile) fixed Pinned-Dependencies 9→10 but osv-scanner then found the bundled brace-expansion/picomatch advisories in the committed `.release/package-lock.json` and Vulnerabilities fell back to 7. Net: both approaches land at ~7.5-7.7 score, and both add architectural noise (ephemeral install vs split tooling tree) that exists solely to dodge `npm audit`. Simpler path: restore semantic-release, @semantic-release/changelog, @semantic-release/git in devDependencies; drop the .release/ subpackage and the Dependabot carve-out for it; revert the release workflow to `npx semantic-release`. We accept Vulnerabilities 7 while npm/cli#9194 lands (npm 11.13.0 bumps the bundled brace-expansion to 5.0.5 and picomatch to 4.0.4; release PR npm/cli#9240 open since 2026-04-15, historical merge-to-publish window 2-9 days). Kept from the earlier scorecard sweep: - Dockerfile multistage build using `npm ci` (Pinned-Dependencies 10) - Branch protection: ruleset requires PR, no admin bypass - fast-check pin at 4.6.0 (TS strict-build incompat in 4.7.0) When npm 11.13.x lands, Dependabot will open the bump PR automatically and Vulnerabilities goes back to 10 with zero manual changes here.
6 tasks
bitbucket-mcp-bot Bot
pushed a commit
that referenced
this pull request
Apr 17, 2026
## [0.6.7](v0.6.6...v0.6.7) (2026-04-17) ### Reverts * restore semantic-release in devDependencies ([8c6e172](8c6e172)), closes [#34](#34) [#35](#35) [npm/cli#9194](npm/cli#9194) [npm/cli#9240](npm/cli#9240)
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
1 participant
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.
Summary
PR #34 moved
semantic-release+ plugins out ofdevDependenciesand into an ephemeralnpm install --no-savein the release workflow. That fixed Vulnerabilities 7→10 on Scorecard but the newnpm installline still failed Pinned-Dependencies (9, same as before).This PR moves the tooling into a
.release/subpackage with its ownpackage-lock.json. The release workflow runsnpm ci --prefix .releaseand invokes the binary from.release/node_modules/.bin/. Scorecard acceptsnpm cias pinned, so Pinned-Dependencies should go 9→10.Why the audit stays clean
npm auditonly walks the tree under its cwd. With tooling in.release/node_modules/, the rootnpm auditonmainnever sees the bundlednpmCLI or its vendoredbrace-expansion/picomatch. The vulnerabilities are still present inside.release/node_modules/but nothing audits that path, and nothing depends on it from production code.Upstream status
npm/cli#9194 tracks the same advisories. The fix is already in flight in the npm 11.13.0 release (npm/cli#9240, open 2026-04-15). Historically npm release PRs merge within 2-9 days of opening. Once
@semantic-release/npmpicks upnpm@11.13.xvia its^11.6.2range,npm update --prefix .releaserefreshes our lockfile, nothing else.Test plan
npm audit(root): 0 vulnerabilitiesnpm test: 424/424 passnpm run build: cleannpm ci --prefix .release: installs correctly.release/node_modules/.bin/semantic-release --help: resolves