[pull] latest from npm:latest#14
Open
pull[bot] wants to merge 795 commits into
Open
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
## 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>
This makes the email prompt in `npm adduser` a bit more friendly (no need to shout) and places the colon at the end like in the other prompts 😃 Works well with the #8322 spinner fix.
This update removes the copied config that is in the description header. We can remove the part about the registry not working yet when the registry enabled this. --------- Co-authored-by: Gar <gar+gh@danger.computer>
## Summary This PR clarifies the documentation for `npm version` to explicitly describe its behavior when the current version is a prerelease version. ## Problem The current documentation states that when using `patch`, `minor`, or `major` arguments, "the existing version will be incremented by 1 in the specified field." However, this is incomplete and misleading when the current version is a prerelease. When the current version is a prerelease (e.g., `1.2.0-5`), running `npm version patch` (or `minor`/`major`) will simply remove the prerelease suffix without incrementing the version number. The result would be `1.2.0`, not `1.2.1`. This undocumented behavior has led to: - Developer confusion when the version doesn't increment as expected - Incorrect guidance from LLMs trained on the incomplete documentation ## Solution Added a note immediately after the existing sentence to clarify this behavior: > **Note:** If the current version is a prerelease version, `patch`, `minor`, and `major` will simply remove the prerelease suffix without incrementing the version number. For example, `1.2.0-5` becomes `1.2.0` with `npm version patch`, not `1.2.1`. ## Testing The documentation change is straightforward and doesn't affect code behavior. The example provided matches the actual behavior of the `semver.inc` function from the node-semver package. Fixes #8637
## Description This PR clarifies that the `--tag` option for `npm install` only applies to packages specified on the command line, and does not override version ranges in `package.json`. ## Changes - Added a note explaining that `--tag` does not affect dependencies listed in `package.json` - Explained that version ranges in `package.json` take precedence over the `--tag` flag - Provided an example showing the correct way to install a tagged version: `npm install foo@beta` ## Context Users were confused when `npm install --tag beta` didn't install beta-tagged versions of dependencies listed in `package.json`. The issue reporter discovered that when `package.json` specifies a version range like `"^0.3.0"`, the `--tag` flag is ignored and npm installs a version matching the range, even if the `beta` tag points to a different version (like `0.4.0-beta.1`). This was marked as needing better documentation/logging to make the behavior less surprising. Closes #4685 Co-authored-by: Max Black <husivm@google.com>
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
<!-- What / Why --> The --json flag for npm view now always returns an array, even when only a single version matches. Previously, a single item result would be unwrapped and returned as a plain object/string, which made programmatic parsing fragile - consumers had to handle both array and non-array shapes depending on how many versions matched. This doc update adds a note to npm-view.md clarifying that the output is always an array when --json is used, reflecting the behavioral fix. ## References Related to npm/statusboard#1074 (comment)
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 : )