-
Notifications
You must be signed in to change notification settings - Fork 0
docs(logging): replace proceeding with preceding in loglevels details… #2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
Aigle9
wants to merge
252
commits into
Aigle9:latest
Choose a base branch
from
npm:latest
base: latest
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
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
#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>
This was removed in npm 7 and never got re-added. In order for this not to be a breaking change the info was added to new fields, since the old fields are already being used to return counts. This differs slightly from the npm 6 output, as "changed" now has a "from" and "to" field instead of a tacked on "previousVersion" field. Closes: #6558
These have 2fa links in them and need to include the uuids. Also un-wraps the comments in lib/utils/display.js as a small cleanup.
## References - Related to #8641 (comment) - Closes #8641 Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>
- inline this.#render logic. The initial setTimeout is only used during load(), so run it there instead. - .unref() the progress bar's recurring timeout object - reuse the progress bar's timeout object with .refresh() instead of making a new one every frame - Minor comment syntax cleanup and remove stale comments - skip clearing the line on the first frame when resuming the spinner - removed the test from #8631 as it was only testing that the very first frame of the spinner didn't clear the line, not any subsequent frames This is built off of #8631, moving the "skip clearing the line..." logic into a flag that's passed during .resume()
Tests for libnpmpublish fail with ci-info@4.3.1 ref: watson/ci-info#140
- reverts pruning added in #8431, which incorrectly prunes deps flagged as `peer` and `optional` - these flags don't mean that this node is an optional peer! - reverts much of #8579, which I think mistakenly changed peer dep calculation logic - rewrites calcDepFlags - adds logic to avoid unsetting `extraneous` when following optional peer edges (how #8431, should have been fixed) - updates my prev fix to avoid looking for missing optional peer deps (`if ((!edge.to && edge.type !== 'peerOptional') || !edge.valid) {`) - refactors dep flag unsetting and resetting into Node methods - removes `shake out Link target timing issue` test, which was testing code [removed](2db6c08#diff-6778dbd4bbfddaeb827a8d2aa7248d4c9b329229f69e407d5fd487abe16dd942L333) a while back - avoids omitting flaky`selflink` fixture when writing snapshots Fixes #8535
Lint left over from #8645
In context this isn't a big deal, the extra slash is usually an artifact of path and url parsing. Linting will not warn about this now though.
The `C` parameter only informs tar where to read from, not where to write to, evidently.
- constructor logic was consolidated. It takes place in the main Arborist constructor when possible, allowing us to see all of the constructor at once and find any duplications or problems. It's evident that our approach to options/this.options needs some attention. - Some small single-use methods were inlined into the code that called them. In many cases this prevented re-pulling variables from `this`. - remove unused param from call to `#linkFromSpec`. The function is not expecting a fourth parameter. - remove unused private attributes, `#dryRun` and `#savePrefix` are not used anymore
Fixes [#8684](#8684) ### What / Why When running `npm token create`, the created authentication token was being redacted in the output, making it difficult for users to copy and use the token. This happened because npm's output system automatically applies redaction to sensitive information like tokens. ### How - Import `META` from `proc-log` to access output metadata options - Use `{ [META]: true, redact: false }` option in `output.standard()` to disable redaction for the token display line - This follows the established pattern used in other parts of the codebase (e.g., `lib/utils/open-url.js`) for displaying sensitive information that users need to see ### Testing - All existing tests pass - The fix preserves the existing output format and test expectations - Token is now displayed in full while maintaining proper formatting and colors ### Before Created publish token npm_*** ### After Created publish token npm_1a2b3c4d5e6f7g8h9i0j The token can now be copied and used directly without being obscured by npm's redaction system. Co-authored-by: Max Black <husivm@google.com>
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