Skip to content
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
wants to merge 241 commits into
base: latest
Choose a base branch
from
Open

[pull] latest from npm:latest #4

wants to merge 241 commits into from

Conversation

pull[bot]
Copy link

@pull pull bot commented Jan 21, 2022

See Commits and Changes for more details.


Created by pull[bot]

Can you help keep this open source service alive? 💖 Please sponsor : )

wraithgar and others added 13 commits July 29, 2024 09:40
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
TrevorBurnham and others added 30 commits February 18, 2025 11:55
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.
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
Projects
None yet
Development

Successfully merging this pull request may close these issues.