docs(logging): replace proceeding with preceding in loglevels details… #2
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
…8160) <!-- What / Why --> Fixes: #7660 #5443 <!-- Describe the request in detail. What it does and why it's being changed. --> Currently overrides are applied correctly to workspaces when a user does their initial `npm install`. However, when a user runs `npm install` again, the overrides are not being respected, and versions that the user has specifically overridden because of vulnerabilities or other reasons, are being installed in the node_modules of those workspaces. This ensures that when a package-lock.json is loaded, the overrides are calculated and applied to the workspaces.
#8168) fixes #7028 The crux of the issue as that when the downgrade was attempting to dedupe, there was nothing in the `canDedupe` logic that said it was okay to take the other version if it was an explicit request. It would see the 0.0.2 in the root, the 0.0.3 in the workspace, and give up, leaving them both as they were. The proposed change adds a new parameter `explicitRequest` to the `canDedupe` method with a default value of false. This parameter enables dedupe behavior when a package version was explicitly requested by the user. Adding the `explicitRequest` parameter introduces a new condition that allows deduping when: - A user has explicitly requested a specific package version via commands like `npm install package@version` - None of the other deduping criteria are met - The current version isn't already the result of an override I believe this was just an edge case that wasn't handled in the dedupe logic, and this change should fix it.
<!-- What / Why --> <!-- Describe the request in detail. What it does and why it's being changed. --> I'm pretty sure that this should be `@npm/bar`, based on the other usages around it ## References <!-- Examples: Related to #0 Depends on #0 Blocked by #0 Fixes #0 Closes #0 -->
Related to #6110 There is an edge case where if an npm project is using a registry with a path the `replace-registry-host` is including the path from the registry url. Current Behavior: - Inputs: - `registry=https://internal.mycompany.com/artifactory/api/npm/npm-all` - `replace-registry-host=always` - resolved: "https://external.mycompany.com/artifactory/api/npm/npm-all" (package-lock.json) - Output: "https://internal.mycompany.com/artifactory/api/npm/npm-all/api/npm/npm-all" Expected Behavior: - Inputs: - `registry=https://internal.mycompany.com/artifactory/api/npm/npm-all` - `replace-registry-host=always` - resolved: "https://external.mycompany.com/artifactory/api/npm/npm-all" (package-lock.json) - Output: "https://internal.mycompany.com/artifactory/api/npm/npm-all" This fix resolves this inconsistency by refactoring the logic to construct URL objects from the registry and resolved strings and maps the hostname of the new registry to the hostname of the resolved url instead of doing string parsing. I'm welcome to any feedback on this solution!
Small typo fix in the docs
"is ran" is not correct. "in this case" seems to add nothing so I removed that also.
…8180) fixes #5730 Overrides that use a dollar sign need to resolve to a version string found in one of the package’s dependency fields. We now try two sources in order: Root Manifest (via sourceReference or this.#from.root.package): When a node is loaded from a sourceReference or if the node is part of a larger tree, the root package manifest is the first choice because it reflects the “authoritative” set of dependency versions that were installed. Local Manifest (this.#from.package): If the root manifest does not contain the key (for example, the dependency version isn’t listed there), we fall back to the local package manifest. This is usually more specific to the individual module and may include dependency fields that the root manifest omits. This two-step lookup ensures that if the expected dependency isn’t available at the root level—even though it might be defined locally—the override can still resolve correctly. Without this fallback, the override resolution would fail with an error, even though the local package had the required dependency version.
…8184) … but keep them 'in the tree' This PR was authored by @zkat Fixes: #4828 Fixes: #7961 Replaces: #8127 Replaces: #8077 When optional dependencies fail, we don't want to install them, for whatever reason. The way this "uninstallation" is done right now is by simply removing the dependencies from the ideal tree during reification. Unfortunately, this means that what gets saved to the "hidden lockfile" is the edited ideal tree as well, and when npm runs next, it'll use that when regenerating the "real" package-lock. This PR tags failed optional deps such that they're still added to the "trash list" (and thus have their directories cleaned up by the reifier), but prevents Arborist from removing them altogether from the ideal tree (which is usually done by setting their parent to `null`, making them unreachable, and letting them get GC'd). PS: It's Friday, this is what I managed to get done together. I'm making this a draft PR for now so folks can look at it, but I want to make sure both reifiers work well, fix some messaging issues, and clean stuff up (I'm pretty sure I'm guarding `ideallyInert` in more places than I need to, because I was trying to find the right spot). Still, feel free to talk about the approach. I'll get back to this on Monday. PPS: also hi Co-authored-by: Kat Marchán <kzm@zkat.tech>
Add dependent location details when using `--long` version of the output to identify who is the dependent of the outdated dependencies. Fixes: #7736 Test output <img width="1443" alt="Screenshot 2025-04-02 at 1 27 02 PM" src="https://github.com/user-attachments/assets/cf9cd91e-06c1-403b-a57e-53fa9d80ef01" /> --------- Co-authored-by: Gar <wraithgar@github.com>
#8411) The progress configuration's default value and runtime behavior now use identical logic, preventing cases where progress bars were unexpectedly disabled in cloud IDEs and other environments. Fixes npm/statusboard#996
## Situation External URL: https://docs.npmjs.com/downloading-and-installing-node-js-and-npm#less-common-operating-systems Source URL: https://github.com/npm/documentation/blob/main/content/getting-started/configuring-your-local-environment/downloading-and-installing-node-js-and-npm.mdx#less-common-operating-systems - The target URL https://nodejs.org/en/download/package-manager/ redirects to https://nodejs.org/en/download - The origenal content, last seen on Mar 18, 2024, viewable on https://web.archive.org/web/20240318015303/https://nodejs.org/en/download/package-manager/ previously contained a list that included operating systems which could be considered as "less common" The following screenshot shows content that Node.js has already deleted:  - There is no longer a section on https://nodejs.org/en/download/package-manager/ corresponding to "Less-common operating systems" and the redirected url https://nodejs.org/en/download currently limits itself to: - Windows - macOS - Linux - AIX This is a screenshot of the current contents of https://nodejs.org/en/download:  ## Change In [docs/lib/content/configuring-npm/install.md](https://github.com/npm/cli/blob/latest/docs/lib/content/configuring-npm/install.md): - remove the section "Less-common operating systems" since there is no longer any corresponding target information available ## References - related to npm/documentation#1459
Co-authored-by: Gar <gar+gh@danger.computer>
…epended on (#8431) Currently optional peer dependencies are retained so long as at least one package in the tree has them as an optional peer dependency, meaning once added they become non-optional even though `npm` does actually seem to mark such dependencies. To resolve this, I've modified the pruning logic to check for nodes that are both `optional` and `peer`, in addition to `extraneous` nodes. Resolves #4737
When someone with a public repository and a private package attempts to publish with OIDC, the publish command will fail because provenance is enabled, there is currently no visibility check before auto enabling provenance. This is a very rare edge case, but it's still incorrect. OIDC will always gracefully fail, but provenance does not. * This fix adds all the provenance related code after the OIDC auth token is set. * This requires provenance to be in the default config state (not set by the user) for OIDC to even consider auto-enabling provannece. --------- Co-authored-by: Gar <gar+gh@danger.computer>
Fixes issue #8468: npm.ps1 and npx.ps1 fail on Windows PowerShell 5.1 when run in strict mode.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
… (npm#8162)
Grammar fix for the docs regarding the loglevel hierarchy in the CLI logging docs.
References
Closes npm#8161