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 #7

Open
wants to merge 1,228 commits into
base: latest
Choose a base branch
from
Open

[pull] latest from npm:latest #7

wants to merge 1,228 commits into from

Conversation

pull[bot]
Copy link

@pull pull bot commented Oct 17, 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 23 commits June 27, 2024 10:59
It has historically not worked very consistently and we don't have the
bandwidth to keep fixing it.
…#7579)

<!-- What / Why -->
If a node represents a symbolic link or a file dep (node.isLink is
true), its target is expected to reference another node in the
dependency tree. If the linking is not done correctly or is incomplete,
node.target might be null.
<!-- Describe the request in detail. What it does and why it's being
changed. -->
in this PR, a null check is added to ensure node.target is not null or
before proceeding, which will prevent causing errors like:
`npm error Cannot set properties of null (setting 'peer')` 

## References
  Related to #7065, 
  Fixes #6622, #5007,
  Closes #6622, #5007
This change solves #4783

<!-- What / Why -->
<!-- Describe the request in detail. What it does and why it's being
changed. -->
During 'npm cache verify', currently all the cache files are open at the
same time, which will bring EMFILE error in an environment that limit
max open files.
This change limits the concurrent open files in garbageCollect() with
p-map module to avoid this problem.

## References
  Fixes #4783
Handle arborist error when loading and checking package in global tree.
This change updates the list of lifecycle scripts in the RunScript class
to include important npm scripts that were previously missing.

- add `prepare`, `prepublishOnly` scripts
- add `dependencies` scripts
- add `prepack` and `postpack` scripts
- todo comments removed due to changes reflected

<!-- What / Why -->
<!-- Describe the request in detail. What it does and why it's being
changed. -->


## References
The documents I referenced are as follows:
- https://docs.npmjs.com/cli/v10/using-npm/scripts

<!-- Examples:
  Related to #0
  Depends on #0
  Blocked by #0
  Fixes #0
  Closes #0
-->
Sometimes computers are slow
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 <hashtagchris@github.com>
`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
wraithgar and others added 30 commits January 30, 2025 08:45
It is not a valid cli flag, single-hyphen flags should all be single-character.  Eventually `-ws` will need to go away so will at least stop suggesting it now.
Single hyphen cli flags traditionally are single-character only, so they
can be combined. npm already supports combining single-hyphen flags
together, so it eventually needs stop supporting multi-character ones.

Also re-added -ws to undocumented shorthands, it was accidentally
removed from the main config and not re-added to the internal one.

Finally, warnings on a few env configs that npm tosses around were
suppressed for now.
Removes all usage of `.replace(/#/g, '%23')` for compatibility with the new version

This is the code changes from #8112 isloated from the dependency update itself.

Closes:
npm/npm-package-arg#203

Credit: @TrevorBurnham
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
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.