[pull] latest from npm:latest #6
Open
Conversation
This file contains 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
![pull[bot]](https://avatars.githubusercontent.com/in/12910?s=60&v=4){kind=small}
fritzy
force-pushed
the
latest
branch
3 times, most recently
from
3037d35 to
f3b0c43
Compare
lukekarrys
force-pushed
the
latest
branch
2 times, most recently
from
591d1d1 to
9e74d3e
Compare
The [Auth related configuration](https://docs.npmjs.com/cli/v10/configuring-npm/npmrc#auth-related-configuration) docs contains a mistakenly commented configuration line. This PR makes the scope examples more clear by adding newlines and uncomment the valid configuration line.
This PR fixes an issue where the `npm publish` command would fail when run from within a workspace directory with package-spec fixes: #7726
Updating Docs for `npmrc` - Updated example config, instead of `prefix` which can not be changed for project, instead added `cache` which can be used for all three config types project, user and global `package-json` - added alias example in package-json docs, which can be used to define alias for a package closes: #6839 closes: #7188
Updated `npm init <pkg-spec>` command usage documentation for npx equivalent command format `npx create-<pkg-spec>` Fixes: #7011
When doing manifest call for fetching npm manifest it was using latest every-time, however fetching`npm@*` will still give `latest` if it's satisfies the engine range otherwise it will give highest matching version for the current engine range. Pacote.manifest calls internally uses pick-manifest logic to pick the appropriate version of the manifest for the engine range.
A first step in fixing the overrides feature. In this PR I'm aiming to fix 3 bugs: 1. When we add an edge going into a node we update the node's overrides, but we don't update the overrides of that node's outgoing edges, and so forth. We need the up-to-date overrides to filter through. 2. When we remove an edge going into a node we don't update the overrides at all (and we don't update the outgoing edges like in the previous bug). 3. When we add an edge going in, and we already have a different override set for the node, we just ignore the existing override set and overwrite it with that of the new edge. Instead, this PR chooses the most specific override set. This still isn't the absolutely correct logic, since different override sets can have implications down the line of the dependency chain, but it has the advantage of being **consistent** (instead of just going with the last edge in). Also, it raises an error if it encounters a real conflict, meaning two incoming edges with override sets that aren't just a subset of one another. So if we have dependency chains A->B->C and A->C, and we override C under B, then C will be overridden. ## References Fixes some of the override [issues](#5850). Primary author: @AlonNavo Co-author: @owlstronaut
…orkspace (#8143) A reworking of the smoke tests to accommodate a recent PR where the check to see if the version has already been published conflicted with the smoke tests. A fix was implemented to add prerelease tags to address this issue. However, when the version bumps are legitimate and a prerelease tag is added, the workspace dependencies still have the version prior to the prerelease tag. This PR adds the prerelease tag and bumps all versions used in the workspace.
node 24 doesn't exist yet
PR #8071 originally had this but that appears to have gotten lost along the way.
This formalizes the `node-gyp` config that is eventually consumed by [@npmcli/run-script](npm.im/@npmcli/run-script). That module will need to be updated so that it can accept this config and use it if found, only falling back to its current behavior by default.
PR makes `npm run` completion to take workspaces into account in case of cwd is inside workspace dir it will autocompletes from `scripts` section of nearest workspace's package. Former behavoiur was to autocomplete everything from workspace root package, it has no sense since when you are in workspace directory script which will be suggested in such manner will not work. So there was a mismatch between the script launch and the autocomplete hint areas. ## References Fixes [#7114](#7114)
Override config `save` to always be `true` when installing to the npx cache. fixes: #8151
…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 -->
…overage (#8174) Related: #8108 This adds test coverage for workspace override functionality Co-authored-by: Trevor Burnham <[email protected]>
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.
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.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )