[pull] latest from npm:latest #14
Open
Conversation
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
![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
If you kick off multiple npx processes at the same time for the same non-local package(s), they can potentially install atop each other in the same npx cache directory. This can cause one or both processes to fail silently, or with various errors (e.g. `TAR_ENTRY_ERROR`, `ENOTEMPTY`, `EJSONPARSE`, `MODULE_NOT_FOUND`), depending on when/where something gets clobbered. See [this issue](#8224) for more context and previous discussion. This pull request introduces a lock around reading and reifying the tree in the npx cache directory, so that concurrent npx executions for the same non-local package(s) can succeed. The lock mechanism is based on `mkdir`s atomicity and loosely inspired by [proper-lockfile](https://www.npmjs.com/package/proper-lockfile), though inlined in order to give us more control and enable some improvements. ## References Fixes #8224 --------- Co-authored-by: Gar <wraithgar@github.com>
Partial revert of #7947 `certfile` and `cafile` are both valid, and are used for different things: - `certfile` is the path to the certificate file. It's used for mutual TLS and represents the client's certificate (supersedes the deprecated `cert`, and complements `keyfile`). - `cafile` is the path to the certificate authority file. It's used to verify the authenticity of the registry's certificate. Also clarify that `keyfile` and `certfile` must be scoped to a registry.
Various improvements to withLock and its tests - fix windows race conditions/errors - use second-level granularity when detecting lock compromise; this resolves a sporadic floating point issue under APFS, and makes this generally more robust no matter the underlying file system - improve touchLock logic so that it doesn't compromise the lock for the next holder or keep running the interval when cleanup fails ## Testing notes Fixes were verified via a [modified GHA workflow](https://github.com/jenseng/cli/actions/runs/17803264354) that ran all the tests 100 times 😅 ## References Related to #8512
Discovered while investigating #8535 `npm install --omit` output doesn't show any removed packages. This PR moves the omit calc into the diff calc so omits are handled like other resolution logic. Improvements: * we see removals in CLI output * _createSparseTree no longer creates dirs that will only be cleaned later * no duplicate filterSet calculation, omit is calculated right after filters I removed the trashList check on reifying node. Code coverage complained that this branch wasn't hit in any tests so I assume it should always be empty. I think this uncovered one bug with workspaces in the test `workspaces > reify workspaces omit dev dependencies > workspaces only`. From my understanding of the [docs](https://docs.npmjs.com/cli/v11/commands/npm-install#include-workspace-root), only workspace `a` should be touched, `root` and workspace `b` should still have their packages. I updated the test. Co-authored-by: Liam Mitchell <liam.mitchell@mendix.com>
Like EEXIST, we handle ENOTEMPTY when we fail to moveFile. A user reported they consistently could not update our CLI tool. [1] In that report it always had the same file it tried to rename to. I believe what is happening here is when NPM retires an old version it renames it to a deterministic path. However, I suspect a previous update was interrupted leaving a non-empty directory at the destination. When googling ENOTEMPTY all the results seem to be about npm failures with users suggesting clearing out node_modules. Maybe this will also solve those issues. [1]: https://gist.github.com/keegancsmith/5dac339583cc127031da6ed0e8512d47
…h prepare - Updated examples section to use prepare and test scripts instead of discouraged install/postinstall - Changed use case recommendations from prepublish to prepare - Replaced CoffeeScript example with TypeScript (more current) - Replaced make commands with modern build tools (tsc, jest) - Fixes #3992
## WHY/WHAT Fixed non-intuitive unit rounding for byte formatting. Previously, values close to a unit boundary (e.g. 999,999 B) displayed incorrectly as the smaller unit. We adjusted the conversion threshold (e.g. to 999,950 B for MB) to leverage standard `toFixed(1)` rounding, ensuring values that are `almost 1.0` of the next unit are correctly displayed as 1.0 MB, prioritizing a better user experience.
Adds proxy-related environment variables to npm config list output to help users understand their proxy configuration. Variables are checked case-insensitively to match the agent library behavior. Closes #4170
As mentioned in the issue #8837, BOM files in cyclonedx format created by npm-sbom contain an invalid statically UUID value in the serialNumber field: `"serialNumber": "urn:uuid:***"`, because it was being redacted each time. This change uses `output.standard()` with `{ [META]: true, redact: false }` to bypass redaction for SBOM output, following the same pattern used in `lib/commands/token.js` for outputting authentication tokens that should not be redacted. **Before:** ```json "serialNumber": "urn:uuid:***" ``` **After:** ```json "serialNumber": "urn:uuid:12345678-1234-1234-1234-123456789abc" ``` <img width="1265" height="518" alt="image" src="https://github.com/user-attachments/assets/fc21aa65-2bef-4336-a55c-e7417ae9eebd" /> ## Testing - All existing tests pass - Verified locally that `serialNumber` now displays the complete UUID ## References Fixes #8837
## Description This PR adds documentation explaining how `npm install` behaves with respect to `package.json` and `package-lock.json`, a common source of confusion for npm users. ## Changes - Added a new section "How `npm install` uses `package-lock.json`" to the `npm install` documentation - Explained the two scenarios: - When `package.json` and `package-lock.json` are in sync: exact versions from lockfile are installed - When they conflict: `package.json` wins and `package-lock.json` is updated - Clarified that `package.json` is the source of truth for version ranges, while `package-lock.json` locks to specific versions - Noted the relationship to `npm ci` behavior ## Context The npm install documentation previously didn't explain how it handles the interaction between `package.json` and `package-lock.json`. Users were confused about when versions from the lockfile are used versus when they're updated. This PR incorporates the explanation from Kat Marchán that was referenced in the issue to provide clear guidance. Closes #4866 Co-authored-by: Max Black <husivm@google.com>
<!-- What / Why --> <!-- Describe the request in detail. What it does and why it's being changed. --> while reading https://docs.npmjs.com/cli/v11/commands/npm-dedupe <img width="1582" height="502" alt="image" src="https://github.com/user-attachments/assets/cc8109a3-6d56-40bb-8cc7-09f6c59e0dd8" /> I realized there's probably a typo/logic error/imprecision: the `c@1.9.0` is mentioned nowhere else. I assume `c@1.9.9` was meant, because it's listed in the dependency graph above. but I have no clue about the inner workings of `npm-dedupe`, so I might be wrong here. --- alternative solution: noting `c@1.9.x`, but not using a range and explicitly matching the listed version above inherits more clarity, at least in my mind ## References <!-- Examples: Related to #0 Depends on #0 Blocked by #0 Fixes #0 Closes #0 --> - https://docs.npmjs.com/cli/v11/commands/npm-dedupe
Also updated diff in dev deps
See jsdom/jsdom#3959 for more info
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 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 : )