[pull] latest from npm:latest#14
Open
pull[bot] wants to merge 790 commits intoGraybar-codespace:latestfrom
Open
[pull] latest from npm:latest#14pull[bot] wants to merge 790 commits intoGraybar-codespace:latestfrom
pull[bot] wants to merge 790 commits intoGraybar-codespace:latestfrom
Conversation
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
The pull request #14 has too many files changed.
We can only review pull requests with up to 300 changed files, and this pull request has 587.
owlstronaut
force-pushed
the
latest
branch
2 times, most recently
from
85ec0c9 to
26b6454
Compare
There is no need to build this every time for a single command that needs it (`npm config list`). It will also allow us to mutate this.data without having to worry about this.
## Description Removes the outdated roadmap link from README.md as the GitHub project board hasn't been updated since 2023 and contains no future items. ## Changes - Removed the Roadmap link from Links & Resources section ## Fixes Closes #7637 ## Rationale The linked roadmap (https://github.com/orgs/github/projects/4247/views/1?filterQuery=npm) only shows 6 shipped items from 2023 with no future roadmap items. Since there's no active replacement roadmap to link to, removing the outdated link provides a better user experience than keeping a dead link. ## Type of Change - [x] Documentation update Co-authored-by: Max Black <husivm@google.com>
## Description Adds an example to the keywords field documentation in package.json to clarify the expected format. ## Changes - Added JSON example showing keywords as an array of strings ## Fixes Closes #7070 ## Type of Change - [x] Documentation update Co-authored-by: Max Black <husivm@google.com>
…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
BREAKING CHANGE: npm no longer registers man pages with the system when installed globally. `man npm-install` will no longer work, but `npm help install` is unaffected.
BREAKING CHANGE: `npm sbom --sbom-format=cyclonedx` now reports the `name` field from each package's `package.json` instead of the on-disk directory name. The `name`, `bom-ref`, and `purl` of the root component and of aliased dependencies may change. fixes: #9178 --------- Co-authored-by: cyphercodes <cyphercodes@users.noreply.github.com>
These complement allow-git.
BREAKING CHANGE: npm pack and npm publish now error when a package's overrides apply to one or more of its bundled packages (bundledDependencies / bundleDependencies). Defining both fields is still allowed as long as no override actually targets a bundled package. To resolve the error, remove the affected entries from either overrides or the bundle.
BREAKING CHANGE: npm view --json now always returns an array.
When a peerOptional edge conflicts, search descendants for a satisfying node before fetching from the registry. This prevents extraneous packages from blocking hoisting of required deps. This fixes 1/2 or 1/3 of #9249. Before this change a clean install would resolve `nm/jest-util@30` when resolving the conflict at nm/jest-util between ts-jest's jest-util@^29||^30, and expect's ^28, which had been placed at root. `#nodeFromEdge` would create a brand new node, matching greatest ^30. A subequent install would mark nm/jest-util@30 as extraneous and prune it. This tree is valid, but ts-jest's peerOptional jest-util is unsatisfied, while compatible jest-util are installed and duplicated. This change reduces duplication and can prevent peerOptionals from actively installing. 1. Now during initial installs npm will prefer hoisting a dependency to de-dupe a peerOptional conflict over creating a new extraneous edge. 2. It doesn't solve the problem if there's no compatible version in the sub-tree. npm will still use `#nodeFromEdge` and install an extraneous edge. 3. It doesn't fix installs from lockfiles generated before this fix. I think this is okay, because the trees are techincally valid, just not optimal. I think a better solution to all three issues would be: * During problemEdge conflict resolution, npm would hoist nm/jest-util@28 under expect, without replacing it with anything. ts-jest's peerOptional jest-util would be unsatisfied. This creates the same tree as npm's second installs that prune extraneous. * Check for any dependencies that can be hosited. This can run during the initial install on problemEdge conflict resoultion, and in pruneIdealTree on any nodes that are removed. I think this solves all three issues. I didn't implement it because I couldn't find a way to resolve the conflict by leaving a hole in the tree..
## Description Fixes #9298. `buildIdealTree` handles global updates by reading the global `node_modules` folder directly and adding each entry as a synthetic top-level dependency. That path did not ignore hidden entries, so a directory like `.hidden-non-package` was converted to `.hidden-non-package@*` and rejected by `npm-package-arg`. This applies the same hidden-entry filter already used by `loadActual`, so hidden directories and retired scoped package folders are not treated as installed global packages during `npm up -g`. ## Testing ```sh node node_modules/tap/bin/run.js workspaces/arborist/test/arborist/build-ideal-tree.js -g "update global ignores hidden" ``` ```sh npm_config_prefix=/tmp/npm-hidden-global-patched.azXmRd node . up -g ``` ```sh node . run eslint -- workspaces/arborist/lib/arborist/build-ideal-tree.js workspaces/arborist/test/arborist/build-ideal-tree.js ```
Exposes a public method on the Arborist class that builds (or reuses) an ideal tree, commits the shrinkwrap metadata, and returns the lockfile contents as a string without writing to disk. This makes a previously-undocumented sequence (`buildIdealTree()` -> `tree.meta.commit()` -> `String(tree.meta)`) a discoverable, supported API, enabling callers to inspect, diff, or store generated lockfiles without mutating the project's package-lock.json.
…9309) 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`, removing a dependency leaves a dangling symlink at `node_modules/<pkg>` (and `<workspace>/node_modules/<pkg>` for workspace deps). The store entry under `node_modules/.store/<pkg>@…` is correctly cleaned up by `#cleanOrphanedStoreEntries`, but the top-level link pointing into it is left behind, so `require('<pkg>')` fails with `Cannot find module` even though the entry still appears in `node_modules/`. The root cause is the same family of issue as #9106. `#buildLinkedActualForDiff` builds the synthetic actual tree from the ideal tree, so any dependency that exists on disk but is no longer in the ideal tree is never compared, and the diff produces no REMOVE action for its top-level symlink. Fixed by extending `#cleanOrphanedStoreEntries` to also collect, per `node_modules` directory (root and each workspace), the set of valid top-level link names from the ideal tree, then sweeping each directory and removing any symlink whose name is not in that set. The root `node_modules` and every workspace's `node_modules` (via `idealTree.fsChildren`) are always seeded into the sweep, so the case of removing the last dependency from the project root or from a workspace still triggers cleanup, including when the workspace itself is declared as a root dependency and therefore has its self-link at the root rather than under its own `node_modules`. The sweep is restricted to symlinks whose target resolves inside the project root, so it covers both store links (e.g. `node_modules/eslint -> .store/...`) and workspace self-links that no longer belong (e.g. `node_modules/a -> ../packages/a` after `a` is undeclared) without touching symlinks that point outside the project, such as those created by `npm link <global-pkg>` without `--save`. Real directories and npm-managed entries (`.bin`, `.store`, `.package-lock.json`) are left alone. The workspace self-link inside its own `node_modules` (e.g. `packages/a/node_modules/a -> ..`) is in the ideal tree as a non-store link, so it's preserved. The sweep also respects the install mode: - It is skipped entirely for `dryRun` and `packageLockOnly` installs, both of which short-circuit `#reifyPackages` and must not mutate `node_modules`. - For workspace-filtered installs (`npm install -w <ws> --install-strategy=linked`), the set of `node_modules` directories to sweep is restricted to the workspaces named in `--workspace`, so dropped dependencies from the in-scope workspace get cleaned up while out-of-scope workspaces and the project root are left untouched. `IsolatedNode`/`IsolatedLink` locations are built with `path.join`, which uses backslashes on Windows; locations are normalized to forward slashes inside the sweep so the parser works on both POSIX and Windows. ## Trade-off This aligns the linked strategy with npm's normal `node_modules`-is-managed model: any in-project symlink that isn't in the ideal tree is treated as orphaned, matching what happens today under the default install strategy. A consequence is that hand-made or unsaved `npm link` symlinks pointing to other paths inside the project root (e.g. `node_modules/foo -> ../examples/foo`) are also swept, since npm doesn't currently record which links it owns and they are indistinguishable from workspace self-links by target alone. A more discriminating ownership check (recording managed link names in the hidden lockfile and only sweeping those) is a worthwhile follow-up but materially larger than this fix. ## References Fixes #9308 Related to #9106
## Summary Closes the per-node duplication gap left by #7992. A node can have multiple outgoing edges resolving to the same `name@version` — typically when a package declares both a direct dependency and an npm alias to the same package, e.g.: ```json { "dependencies": { "lodash": "^4.17.21", "lodash-aliased": "npm:lodash@^4.17.21" } } ``` `toCyclonedxDependency` and the SPDX relationship loop both map each edge through `name@version` ID generation without deduplicating, so the per-node `dependsOn` array (CycloneDX) and `DEPENDENCY_OF` relationships (SPDX) end up with duplicate entries. CycloneDX 1.5 requires `dependsOn` items to be unique, so downstream validators (e.g. Dependency Track) reject the SBOM with: ``` $.dependencies[N].dependsOn: must have only unique items in the array ``` ## Changes - `lib/utils/sbom-cyclonedx.js`: wrap the `dependsOn` array in `[...new Set(...)]` after mapping edges to refs. - `lib/utils/sbom-spdx.js`: dedupe per source-node relationships by the `(spdxElementId, relatedSpdxElement, relationshipType)` triple. - Test cases added to both `test/lib/utils/sbom-cyclonedx.js` and `test/lib/utils/sbom-spdx.js` covering the duplicate-edges-to-same-target scenario, with explicit assertions plus snapshot updates. ## Test plan - [x] `node . run test -- test/lib/utils/sbom-cyclonedx.js test/lib/utils/sbom-spdx.js` — passes - [x] 100% coverage on both touched files - [x] Snapshot diff is purely additive (no existing snapshots changed) - [x] Schema-validation tests in both files still pass for all snapshots - [x] Reproduced original issue locally with the alias example, ran patched npm against it, confirmed both CycloneDX `dependsOn` and SPDX relationships are now deduped Fixes #9310
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 : )