-
Notifications
You must be signed in to change notification settings - Fork 0
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
[pull] latest from npm:latest #4
Open
pull
wants to merge
241
commits into
NOUIY: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.
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
e930921
to
dd63e21
Compare
3037d35
to
f3b0c43
Compare
591d1d1
to
9e74d3e
Compare
An erroneous assumption was that if this was explicitly set, then the exit was still intentional. This is not the case. Closes: #7672 --------- Co-authored-by: Chris Sidi <[email protected]>
`npm init` calls `libnpmexec` with path and runPath, for most cases it would not matter but when we have a package installed locally on root and we want to run `npm init that-package -w workspace` it should identify that-package is installed and use that to init new workspace package. here the `path` is where node_modules are and `runPath` is cwd to run the command. Fixes: #7700
Following up on #8115. Since `cleanFetchSpec` no longer differs from `fetchSpec`, it's no longer needed. cc @wraithgar
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.
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 : )