[pull] latest from npm:latest - #10
Open
pull[bot] wants to merge 2198 commits into
Open
Conversation
|
fritzy
force-pushed
the
latest
branch
3 times, most recently
from
September 14, 2022 23:09
3037d35 to
f3b0c43
Compare
lukekarrys
force-pushed
the
latest
branch
2 times, most recently
from
October 19, 2022 19:50
591d1d1 to
9e74d3e
Compare
owlstronaut
force-pushed
the
latest
branch
2 times, most recently
from
March 27, 2025 18:03
85ec0c9 to
26b6454
Compare
BREAKING CHANGE: npm will no longer attempt to resolve the path to node via whichnode. process.execPath is already set by Node to the resolved real path of the node binary, so the lookup was redundant. Scripts that expected npm to override process.execPath with a PATH-resolved (potentially symlinked) node path may be affected.
…es (#9235) Fixes #9227 `npm install` hangs when a project uses `bundledDependencies` and `overrides` targeting a transitive dep shared by multiple bundled deps. In `edge.js` `satisfiedBy()`, the `inBundle` check (added in #4963) uses `rawSpec` for bundled nodes to prevent overrides from applying to pre-resolved deps inside a dependency's tarball. However, `inBundle` is also true for deps the root itself will bundle - these are freshly resolved from the registry and overrides should apply. The override was always applied at placement time (correct version installed), but the edge stayed invalid because `satisfiedBy` checked `rawSpec`. Two bundled deps sharing the overridden transitive dep would endlessly re-queue each other via REPLACE. The fix changes `inBundle` to `inDepBundle`, which is only true when the bundler is a non-root package. This preserves the #4963 behavior for deps pre-resolved inside a dependency's bundle/shrinkwrap while allowing the root's overrides to work. Note: it is unclear whether overrides _should_ be applied to deps that will be bundled or shrinkwrapped. The comment says that we explicitly don't, but I can't find supporting docs, and the existing behavior is that overrides are applied to dependencies that will be bundled/shrinkwrapped. I added tests asserting that behavior. These new tests passed without the change: - overrides do not apply inside a dependency that bundles - node bundled inside a dependency uses rawSpec - node inside a shrinkwrap uses rawSpec These new tests failed, they produced the same tree, but the edges were marked invalid: - node bundled by root uses overridden spec - overrides apply to deps the root will bundle and edges are valid This test hung forever: - does not infinite loop In both cases overrides that are 'baked into' dependnecies appear as 'invalid'. This happens because the root package doesn't read the bundler's overrides, and doesn't know why the shrinkwrap/bundle included the out-of-spec version. This commit doesn't affect that behavior.
In continuation of our exploration of using `install-strategy=linked` in the [Gutenberg monorepo](WordPress/gutenberg#75814), which powers the WordPress Block Editor. When using `install-strategy=linked`, npm overrides for transitive dependencies were ignored. The overridden version was installed but reported as `invalid` instead of `overridden`, and with `strict-peer-deps` the install failed entirely with `ERESOLVE`. The root cause is that override propagation stops at Link nodes and never reaches their targets. Overrides propagate through the tree via `addEdgeIn` -> `updateOverridesEdgeInAdded` -> `recalculateOutEdgesOverrides`. When a Link node receives overrides, `recalculateOutEdgesOverrides` iterates over `this.edgesOut` — but Links have no `edgesOut` (their targets do). So overrides never reach the target node's dependency edges, and those edges use `rawSpec` instead of the overridden spec. In the linked strategy, all packages in `node_modules/` are Links pointing to targets in `.store/`. This meant no overrides propagated past the first level of the dependency tree. The fix overrides `recalculateOutEdgesOverrides` in the `Link` class to forward overrides to the target node. When `buildIdealTree` creates a root Link (e.g. on macOS where `/tmp` -> `/private/tmp`), the target Node is now created with `loadOverrides: true` so it loads override rules from `package.json`. The `#applyRootOverridesToWorkspaces` workaround method is removed — it was compensating for this exact bug by detaching workspace edges whose specs didn't match. With proper propagation, workspace edges already have the correct overridden spec, making the workaround dead code. ## References Fixes #9197
`npx` unconditionally re-reifies `file:`/directory specs on every invocation, even when the package is already installed in the npx cache. This happens because `missingFromTree()` has an early return for directory specs that bypasses the cache lookup entirely. Registry packages correctly skip reify on cache hit by checking `node.package.resolved === manifest._resolved`, but directory specs never reach that check. The fix makes two changes to `missingFromTree()` in `libnpmexec/lib/index.js`: 1. The early return for directory specs is now scoped to non-npx trees (`!isNpxTree`), so the npx cache tree is actually consulted on subsequent runs. 2. Added `node.realpath === manifest._resolved` as an alternative match condition, since `file:` spec nodes in the npx cache have `undefined` for `package.resolved` but their `realpath` contains the matching absolute path. A regression test verifies that running `exec` twice with the same `file:` spec only triggers `reify` once (on the cold cache run). ## References Fixes #9251
BREAKING CHANGE: The Twitter and Freenode profile fields have been removed from the npm registry. This means that users will no longer be able to set or view these fields in their npm profiles.
BREAKING CHANGE: `npm shrinkwrap` is removed, the `shrinkwrap` config alias is removed, and `npm-shrinkwrap.json` is no longer loaded or honored at the project root or from inside dependency tarballs. Rename project-root `npm-shrinkwrap.json` to `package-lock.json`; use `bundleDependencies` if you need to ship a locked dependency tree.
BREAKING CHANGE: The `npm pkg` output is no longer forced to json. This means you can get single values without having to worry about wrapping of the values. It also outputs non-json content more similarly to `npm view`. Fixes npm/statusboard#1080
Unknown configuration keys in .npmrc files now emit a warning by default, restoring pre-npm-12 behavior, instead of throwing. This reverts the breaking change from 979518d (#9276) for file-based configs. The new `strict-npmrc` config (default false) opts back into treating them as a hard error. Unknown CLI flags and abbreviations continue to error regardless of this setting.
## What / Why #9729 reverts the `.npmrc` file-config half of the breaking change from `979518d` (#9276): unknown `.npmrc` configs warn by default again, and the new `strict-npmrc` config opts back into erroring. Unknown CLI flags and abbreviations still throw. The `12.0.0-pre.1` changelog entry still carried the original wording, which claimed unknown `.npmrc` configs now throw. Since release-please aggregates every prerelease `BREAKING CHANGE` note into the eventual stable `v12.0.0` release notes, that stale line would surface (inaccurately) in the 12.0.0 notes. This corrects the wording in place. ## Change Edits the single breaking-changes bullet in the `## [12.0.0-pre.1]` section: > unknown CLI flags, abbreviated flags, and single-hyphen multi-char shorthands now throw instead of warning. (Unknown `.npmrc` configs still warn by default; opt into erroring with the new `strict-npmrc` config.) ## Notes - Manual, targeted edit to an already-released, release-please-generated section — this does not disturb release-please, which derives versions from git tags + commit history and only prepends new sections. Precedent: #8298 (`chore: add contributor to changelog entry`). - Best merged alongside / after #9729 so the corrected note reflects shipped behavior. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This PR fixes #9722. `mock-registry` pinned `@npmcli/arborist@^9.1.2`, which meant the local workspace version wasn't linked and the dependency was pulled from the registry instead. `sigstore@^4` got installed at the root node_modules and `^5` was put into `workspaces/libnpmpublish/node_modules`. The dev-only `^4` was then excluded when npm was packed. Fix: - `mock-registry`: arborist `^9.1.2` -> `^10.0.0` - `workspaces/arborist`: validate-npm-package-name `^7.0.2` -> `^8.0.0` (need to release a patch for arborist) - Lockfile regenerated via install + dedupe; `node . run dependencies` The packed tarball now contains `package/node_modules/sigstore` and `publish --dry-run` from the extracted tarball succeeds.
npm 12.0.0 breaks downstream updaters by returning nested arrays for
`npm view <pkg> versions --json`.
## The bug
On npm 12.0.0, a single array-valued field is wrapped in the outer
results array:
```
$ npm view abbrev versions --json
[["1.0.3","1.0.4", ...]] # should be ["1.0.3","1.0.4", ...]
```
This happens in `lib/commands/view.js` `#packageOutput`: for a
single-field query it maps to `res.map(m => m[first[0]])`, and when that
field's value is itself an array (e.g. `versions`), it gets
double-wrapped.
## The fix
Return a sole array-valued JSON result directly instead of adding a
second result wrapper. Existing output shapes are preserved:
- scalar and object results still return in an array (`["1.0.0"]`,
`[{...}]`)
- multiple matching versions keep the result boundary (`[[...],[...]]`)
- a single array-valued result is returned directly
(`["1.0.0","1.0.1"]`)
Docs and tests updated to cover flat array, nested array,
object-wrapper, workspace, and multi-match cases.
Co-authored-by: Martin Ruiz <martin.ruiz.mares@gmail.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…9746) The `bin links adding and removing` test in `workspaces/arborist/test/arborist/reify.js` reifies `rimraf@2.7.1` without setting up a mock registry. This adds `createRegistry(t, true)` so the test uses the mock registry instead of depending on the real one. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
## Problem The `build nodejs` jobs in `Release Integration / publish` fail at `.github/workflows/node-integration.yml`: ``` node . pack --loglevel=silent --json | jq -r .[0].filename → jq: error (at <stdin>:9859): Cannot index object with number → Process completed with exit code 5 ``` As of #9247 (sync json output of pack and publish), `npm pack --json` no longer outputs an array. `logTar` now buffers `{ [tar.name]: tarball }`, so the output is an object keyed by package name: ```json { "npm": { "filename": "npm-12.0.1.tgz", ... } } ``` The workflow still parsed it with `.[0].filename`, which errors on an object. npm 12.0.x is the first release carrying this change, so the release integration only started breaking now. ## Fix Parse the filename from the object instead of an array index: ```diff -npmtarball="$(node . pack --loglevel=silent --json | jq -r .[0].filename)" +npmtarball="$(node . pack --loglevel=silent --json | jq -r 'to_entries[0].value.filename')" ``` Verified locally: returns `npm-12.0.1.tgz`. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
## What / Why `npm audit` can report that a fix is available through `npm audit fix` when the highest safe version inside the declared dependency range is older than the installed version. Arborist already selects that safe candidate using the advisory range, but `CanPlaceDep` rejects it because replacement candidates normally must be newer than the installed version. This causes `npm audit fix` to complete without applying the advertised remediation. ## How - Pass the existing audit report from `PlaceDep` into `CanPlaceDep` and recursive peer placement checks. - Permit an older candidate only when: - the installed node is vulnerable; - the candidate is not vulnerable; and - the candidate passes the existing replacement and peer dependency checks. - Preserve existing no-downgrade behavior for ordinary installs and updates. - Add synthetic, strictly mocked regressions covering: - compatible safe downgrades; - non-audit placement; - still-vulnerable candidates; - peer conflicts; - actual tree replacement; and - metavulnerability removal by pruning a vulnerable transitive dependency. This does not change audit reporting or `--force` behavior. Fixes outside declared dependency ranges still require `npm audit fix --force`. ## Testing - Focused Arborist placement and audit tests - npm command-level audit tests ## References Fixes #9557 Fixes #9718 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Installing a package whose peers form a cycle with an already-installed optional peer could crash with `TypeError: Cannot read properties of null (reading 'explain')` instead of resolving or reporting a real conflict. A minimal trigger: `vite@8.1.4` declares an optional peer on `@vitejs/devtools`, `@vitejs/devtools` peers back on `vite`, so installing vite and then adding devtools crashes. The root cause is in `#loadPeerSet`. While resolving a package's peer edge through the parent's edge, the recursive `#nodeFromEdge` call can place a compatible peer that replaces and detaches the current node from the tree mid-iteration. The now-invalid edge then reached `#failPeerConflict`, whose `#explainPeerConflict` calls `node.resolve(edge.name).explain()` on the detached node. `resolve()` returns `null` for a node no longer in the tree, so `.explain()` threw. A detached node has been superseded by a compatible peer, so there is no real conflict to report. The fix adds a guard that stops processing when the node has been detached, right before `#failPeerConflict`, mirroring the existing top-of-loop detachment check. This lets the install complete by keeping the compatible peer that replaced the node (for the reproduction, `@vitejs/devtools` backs off to a version that satisfies vite's optional peer range) rather than crashing or raising a spurious `ERESOLVE`. ## References Fixes #5222 Closes #4787
) ## Summary Fixes #9802. Before the npm 12 stable cut, #9729 restored warn-by-default for unknown `.npmrc` keys (with `strict-npmrc` to opt into errors). #9733 updated the `12.0.0-pre.1` changelog bullet to match, but the aggregated stable `12.0.0` / `@npmcli/config@11.0.0` breaking-change notes (and the config package's `pre.1` note) still said unknown `.npmrc` configs throw. That stale line also shipped in the published [v12.0.0 GitHub release notes](https://github.com/npm/cli/releases/tag/v12.0.0). This aligns those changelog bullets with the corrected wording: > unknown CLI flags, abbreviated flags, and single-hyphen multi-char shorthands now throw instead of warning. (Unknown `.npmrc` configs still warn by default; opt into erroring with the new `strict-npmrc` config.) Maintainers may also want to refresh the published `v12.0.0` release body to match; that cannot be updated via this PR alone. ## References - #9729 (warn instead of error on unknown `.npmrc` configs) - #9733 (clarified the `pre.1` changelog note)
## Summary Ensure `npm owner add` and `npm owner rm` resolve users from the same registry used for the target package. The user lookup now receives the package `spec`, allowing `npm-registry-fetch` to honor scoped registry configuration instead of falling back to the global registry. ## Testing Added regression coverage for split global/scoped registry configurations, including: - Preventing substitution of the user added as an owner. - Preventing removal of an unintended existing owner. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 1e1231bc-474e-4a27-8b78-242366f48e19
Make `npm pack` honor `min-release-age-exclude` when resolving packages from a registry. Given: ```ini min-release-age=7 min-release-age-exclude=@myscope/* ``` `npm pack @myscope/some-package@1.2.3` incorrectly failed with ETARGET when the package was newer than seven days, despite matching the exclusion. Root cause `min-release-age` is flattened into the `before` option consumed by `pacote` . However, `pacote` does not interpret `min-release-age-exclude` ; callers must remove before for matching packages. `npm pack` performs two manifest resolutions: 1. Directly through `pacote.manifest` 2. Internally through `libnpmpack` Both resolutions received the unmodified `before` option, so the exclusion was never applied. Fix Derive effective options for each package spec using the existing Arborist release-age helpers: • Clear `before` when the package matches `min-release-age-exclude` • Preserve the cutoff for nonmatching packages • Pass the same effective options to both manifest resolutions Using the alias target prevents an excluded alias name from disabling the release-age policy for an unrelated package. Test coverage Added regression coverage confirming that: • A recently published scoped package matching an exclusion glob can be packed • An excluded alias name does not exempt its non-excluded registry target The original scenario was also reproduced against a local registry: it failed with `ETARGET` before this change and successfully produced the tarball afterward. References Fixes #9759 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: dec204b6-ad66-45a5-8228-831e306f6ba6
…tegration (#9822) ## What / Why The `node-integration` workflow passed `--nodedir` as an npm **CLI flag** to `npm install`. In npm 12 unknown configs are no longer accepted, so this now fails with `EUNKNOWNCONFIG`: ``` npm error code EUNKNOWNCONFIG npm error Unknown cli flag: npm error - --nodedir ``` (seen in the Release Integration citgm jobs, e.g. `citgm - bcrypt@6.0.0`). `nodedir` is a **node-gyp** option, not an npm config — it only ever worked via npm's old "accept arbitrary config and re-export as `npm_config_*`" behavior, which node-gyp itself notes was deprecated in npm v11 ([nodejs/node-gyp#3156](nodejs/node-gyp#3156)). ## Change Export `npm_package_config_node_gyp_nodedir` instead of using the CLI flag. This is node-gyp's preferred prefix since npm v11: node-gyp reads it directly from the environment, and npm does **not** warn on it — unlike `npm_config_nodedir`, which currently warns and is slated to error in npm 13. This also matches how upstream [nodejs/citgm](https://github.com/nodejs/citgm) supplies `nodedir` (via env, not a CLI flag). Applied to both the generated `.github/workflows/node-integration.yml` and its `scripts/template-oss/node-integration-yml.hbs` template; `template-oss-apply --lint` passes. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 6e300b82-303b-49ac-ae93-52d984743d5b
## Summary Add the omitted npm 12 breaking-change note explaining that dependency lifecycle scripts are blocked by default unless covered by `allowScripts`, including the approval and rebuild workflow. ## Cause The change was introduced in [`5cd5150`](5cd5150). Although its message described a v12-only default flip, it used `feat:` instead of `feat!:` and did not include a `BREAKING CHANGE:` footer. Release Please therefore classified it as a regular feature and omitted it from the aggregated npm 12 breaking-change notes. ## Release notes The published [`v12.0.0` GitHub release](https://github.com/npm/cli/releases/tag/v12.0.0) was corrected manually with the same breaking-change entry. This PR corrects the source-controlled changelog used by the npm documentation site. ## Manual correction process If a breaking change is omitted from release notes in the future: 1. Do not rewrite the merged commit. Add the missing entry under the released version’s `⚠️ BREAKING CHANGES` section in the root `CHANGELOG.md` and submit a documentation PR. 2. After the PR merges, the npm documentation repository’s scheduled **Update CLI** workflow copies the root changelog into the corresponding CLI documentation page and publishes it. Dispatch that workflow manually if the docs need to update immediately. 3. Update the existing GitHub release separately because a changelog PR cannot modify an already-published release. Preserve the complete current release body before editing it because `gh release edit --notes-file` replaces the entire body: ```bash gh release view <tag> --repo npm/cli --json body --jq .body > release.md # Add the same breaking-change entry to release.md. gh release edit <tag> --repo npm/cli --notes-file release.md ``` 4. Verify that the source changelog, npm documentation page, and GitHub release contain identical wording. To prevent the omission, breaking commits must use a conventional-commit breaking marker such as `feat!:` and include a `BREAKING CHANGE:` footer describing the user-visible impact. Fixes #9750
…9836) ## Situation If the GitHub Actions [.github/workflows/node-integration.yml](https://github.com/npm/cli/blob/latest/.github/workflows/node-integration.yml) workflow "nodejs integration" is run, it outputs multiple deprecation warnings, including the text "Node.js 20 is deprecated." and referring to the blog article [Deprecation of Node 20 on GitHub Actions runners](https://github.blog/changelog/2025-09-19-deprecation-of-node-20-on-github-actions-runners/) dated September 19, 2025. ## Change Update action usage in [scripts/template-oss/node-integration-yml.hbs](https://github.com/npm/cli/blob/latest/scripts/template-oss/node-integration-yml.hbs) to latest versions with `runs.using` `node24`: | BEFORE | AFTER | | ------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------ | | [actions/cache@v3](https://github.com/actions/cache/tree/v3) | [actions/cache@v6](https://github.com/actions/cache/tree/v6) | | [actions/download-artifact@v4](https://github.com/actions/download-artifact/tree/v4) | [actions/download-artifact@v8](https://github.com/actions/download-artifact/tree/v8) | | [actions/github-script@v6](https://github.com/actions/github-script/tree/v6) | [actions/github-script@v9](https://github.com/actions/github-script/tree/v9) | | [actions/upload-artifact@v4](https://github.com/actions/upload-artifact/tree/v4) | [actions/upload-artifact@v7](https://github.com/actions/upload-artifact/tree/v7) | ## Verification Run workflow `node-integration` with: nodejs: 26.5.1 npm version: 12.0.2 Confirm that there are no longer deprecation warnings output. ## References - closes #9834
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
19 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.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )