profile
viewpoint
isaacs isaacs GitHub Oakland CA http://blog.izs.me Principal Engineer at GitHub npm inventor, founder npm, Inc. Former Node BDFL. All opinions are my own. Literally all of them. I own them all. He/him

indutny/caine 141

Friendly butler

isaacs/abbrev-js 141

Like ruby's Abbrev module

isaacs/async-cache 117

Cache your async lookups and don't fetch the same thing more than necessary.

dawsbot/config-chain 96

Handle configuration once and for all

isaacs/block-stream 48

A stream of fixed-size blocks

isaacs/.vim 44

My vim settings

dominictarr/stream-punks 40

discussion repo for streams

isaacs/back-to-markdown.css 22

Turns any markdown editor into a WYSIWYG editor

isaacs/ahyane 11

A blog engine that builds html from text files.

isaacs/blog.izs.me 9

Gatsby app that powers my blog

push eventnpm/arborist

isaacs

commit sha 5280e518e66bbde606038e8bfeeba8cf878a6fe1

use a linter We have more people contributing to this library now, so adding some automated consistency is looking more and more important. Also, this found a few unused variables, which highlighted a bug, albeit a harmless one: a timer string was being created, but then no timer being attached to Shrinkwrap loading. (That's why the reify snapshot is updated.) Some other light refactoring was done in a few places to get eslint to produce a reasonably readable output, and I think mostly for the improvement of readability. I don't 100% agree with every choice the linter is making here. Specifically, I prefer using {} around single-line blocks in some cases, especially loops, but they are omitted most of the time, so that's the way I set the config. Consistency is good though, and this will help us maintain it. Linting is set up as a posttest operation, so we can catch things without having it stubbornly refuse to even run tests until it's all sparkling.

view details

push time in 2 days

PR opened npm/arborist

use a linter

We have more people contributing to this library now, so adding some automated consistency is looking more and more important.

Also, this found a few unused variables, which highlighted a bug, albeit a harmless one: a timer string was being created, but then no timer being attached to Shrinkwrap loading. (That's why the reify snapshot is updated.) Some other light refactoring was done in a few places to get eslint to produce a reasonably readable output, and I think mostly for the improvement of readability.

I don't 100% agree with every choice the linter is making here. Specifically, I prefer using {} around single-line blocks in some cases, especially loops, but they are omitted most of the time, so that's the way I set the config. Consistency is good though, and this will help us maintain it.

Linting is set up as a posttest operation, so we can catch things without having it stubbornly refuse to even run tests until it's all sparkling.

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

References

<!-- Examples: Related to #0 Depends on #0 Blocked by #0 Fixes #0 Closes #0 -->

+5022 -2254

0 comment

31 changed files

pr created time in 2 days

push eventnpm/arborist

Brian Jenkins

commit sha 89581967a4c2abbbd9c570c53d7187303fdf14cb

Check engine and platform when building ideal tree

view details

Brian Jenkins

commit sha 424cc70ae834c4b41edbee9aebca48ba4f57e94b

Add test packages to registry mocks

view details

Brian Jenkins

commit sha da93ff1493004ddc9b51e87f9d52b53723754f67

Don't check engine or platform of optional dependencies PR-URL: https://github.com/npm/arborist/pull/143 Credit: @bonkydog Close: #143 Reviewed-by: @isaacs

view details

push time in 2 days

PR closed npm/arborist

Reviewers
Check engine and platform when building ideal tree

Move engine and platform checks from the reify stage (which only runs when node_modules is modified) to the "build ideal tree" stage.

References

Fixes https://github.com/npm/arborist/issues/134

+325 -68

0 comment

14 changed files

bonkydog

pr closed time in 2 days

create barnchnpm/arborist

branch : isaacs/lint

created branch time in 2 days

Pull request review commentnpm/arborist

Check engine and platform when building ideal tree

 module.exports = cls => class IdealTreeBuilder extends cls {     return this.idealTree   } +  [_checkEngineAndPlatform] () {+    // engine/platform checks throw, so start the promise chain off first+    return Promise.resolve()+      .then(() => {+        for (const node of this.idealTree.inventory.values()) {+          if (!node.optional) {+            this[_checkEngine](node)+            this[_checkPlatform](node)+          }+        }+      })+  }++  [_checkPlatform] (node) {+    checkPlatform(node.package, this[_force])+  }++  [_checkEngine] (node) {+    const { engineStrict, npmVersion, nodeVersion } = this.options+    const c = () => checkEngine(node.package, npmVersion, nodeVersion, this[_force])++    if (engineStrict)+    c()+    else {+      try {+        c()+      } catch (er) {+        this.log.warn(er.code, er.message, {+          package: er.pkgid,+          required: er.required,+          current: er.current,+        })+      }+    }+  }+   [_parseSettings] (options) {     const update = options.update === true ? { all: true }       : Array.isArray(options.update) ? { names: options.update }-      : options.update || {}+        : options.update || {}

Shouldn't indent here. I'll add a eslintrc soon :)

bonkydog

comment created time in 2 days

PullRequestReviewEvent
PullRequestReviewEvent

issue commentnpm/pacote

[BUG] pacote.extract resolves to the wrong value

What spec are you using that's creating this result? I can't reproduce it.

jdmarshall

comment created time in 2 days

pull request commentnpm/rfcs

describe how npm 7 handles peer conflicts

It seems like it would be more ideal to, when a dep graph would have passed with --strictPeerDeps, ensure that future installs operate with strictPeerDeps. That way, an invalid dep graph can still be installed as users migrate to npm 7, but a valid dep graph can't suddenly become invalid without failing the install.

This leaves you vulnerable to failing the install of a meta dep changes in such a way that the peer deps become invalid (but overrideably so).

Strict peer deps kind of has to be either the default always, or explicitly opt in, I think.

isaacs

comment created time in 3 days

Pull request review commentnpm/rfcs

describe how npm 7 handles peer conflicts

+# Handling Conflicting `peerDependencies`++## Summary++Detect unresolvable `peerDependencies` in packages being installed, and+provide mechanisms for users to decide whether this should be treated as a+failure or a warning.++## Motivation++With the move in npm v7 to [install+`peerDependencies`](./0025-install-peer-deps.md), npm now has the capacity+to enter "dependency hell", where a package cannot be installed correctly+because its `peerDependencies` conflict with other packages in the tree.++For example, given the following dependency graph:++```+project -> (x@1, y@2)+x@1 -> PEER(y@1)+y@2 -> PEER(x@2)+```++The project cannot correctly install both `x@1` and `y@2` at the same point+in the dependency tree, because the peer dependency from `x@1` will always+conflict with the dependency on `y@2`.  And if it does, then the peer+dependency from `y@2` on `x@2` will conflict with the dependency on `x@1`.++If `project` is published and used as a dependency, there is no way for it+to get correct dependencies with any arrangement of nesting.  If `project`+resolves `x` to `x@1`, and `y` is installed at or above `x` in the tree,+then `x` will resolve to the same version of `y` that `project` does.++Since `peerDependencies` were _not_ installed by default for so long,+the inclusion of required `peerDependencies` fell to the module with the+dependency.  Thus, this sort of conflict is widespread within the npm+package ecosystem.++While the most effective way to get these issues discovered and fixed would+likely be to fail the install in these situations, it also would make it+impossible for many users to upgrade to npm v7, which is not ideal.++In many cases, the "expected" resolution can be determined by treating+`peerDependencies` as lower priority than direct dependencies of the+package depending on the peer dependency set.++For example, in the conflict described above, we could reasonably infer+that, at least for the purposes of `project`, using `x@1` and `y@2`+together is the intent, in spite of their stated conflict, because the+package bringing in these dependencies has an explictly stated dependency+on each of them.++In other situations, the expected result is more difficult to determine.+For example:++```+project -> (x@1, y@2)+x@1 -> PEER(z@1)+y@2 -> PEER(z@2)+```++In this situation, there is no explicit dependency on `z`, and thus no way+to know the intent of the author of `project`.++Also, a user encountering a conflict caused by a dependency is in a much+different position than a user encountering a conflict in their own+project.  Failing a build due to meta-dependencies is annoying and+frustrating; failing a build due to incorrect direct dependencies is+helpful and actionable.++Thus, it is sensible to have different behavior for conflicts caused by+dependencies than for those caused by the root project or one of its+workspaces.++## Detailed Explanation++When the `--legacy-peer-deps` flag is set, ignore `peerDependencies`+entirely.  This makes npm v7 behave effectively the same as npm v3 through+v6.  The `--legacy-peer-deps` flag is _never_ set for `npm ls`, so that npm

ls passed legacyPeerDeps: false in the arborist options regardless of what the config says.

isaacs

comment created time in 3 days

PullRequestReviewEvent

PR opened npm/rfcs

describe how npm 7 handles peer conflicts

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

References

<!-- Examples: Related to #0 Depends on #0 Blocked by #0 Fixes #0 Closes #0 -->

+337 -0

0 comment

1 changed file

pr created time in 4 days

create barnchnpm/rfcs

branch : isaacs/handling-peer-conflicts

created branch time in 4 days

issue closednpm/cli

[BUG] Some packages can no longer be installed with npm v7

Current Behavior:

Some packages can no longer be installed with NPM v7 (in my case, it's react-tooltip@3.11.6)

To me, the install fails for a pretty legitimate reason. Yet, this behavior is not backward compatible.

Here is the relevant log

npm verb stack Error: Invalid tag name ">=^16.0.0": Tags may not have any characters that encodeURIComponent encodes.
npm verb stack     at invalidTagName (/usr/lib/node_modules/npm/node_modules/npm-package-arg/npa.js:91:15)
npm verb stack     at fromRegistry (/usr/lib/node_modules/npm/node_modules/npm-package-arg/npa.js:296:13)
npm verb stack     at Function.resolve (/usr/lib/node_modules/npm/node_modules/npm-package-arg/npa.js:81:12)
npm verb stack     at Arborist.[nodeFromEdge] (/usr/lib/node_modules/npm/node_modules/@npmcli/arborist/lib/arborist/build-ideal-tree.js:680:22)
npm verb stack     at Promise.all.peerEdges.map.edge (/usr/lib/node_modules/npm/node_modules/@npmcli/arborist/lib/arborist/build-ideal-tree.js:778:48)
npm verb stack     at Array.map (<anonymous>)
npm verb stack     at Arborist.[loadPeerSet] (/usr/lib/node_modules/npm/node_modules/@npmcli/arborist/lib/arborist/build-ideal-tree.js:778:17)
npm verb stack     at (anonymous function).then.node (/usr/lib/node_modules/npm/node_modules/@npmcli/arborist/lib/arborist/build-ideal-tree.js:692:32)
npm verb stack     at process._tickCallback (internal/process/next_tick.js:68:7)
npm verb cwd /home/user/Desktop/test
npm verb Linux 3.13.0-24-generic
npm verb argv "/usr/bin/node" "/usr/bin/npm" "i" "react-tooltip@3.11.6" "-dd"
npm verb node v10.14.0
npm verb npm  v7.0.0-beta.7
npm ERR! code EINVALIDTAGNAME
npm ERR! Invalid tag name ">=^16.0.0": Tags may not have any characters that encodeURIComponent encodes.
npm verb exit 1

Expected Behavior:

npm install works flawlessly

Steps To Reproduce:

npm init -y
npm i react-tooltip@3.11.6

closed time in 5 days

debel27

issue commentnpm/cli

[BUG] Some packages can no longer be installed with npm v7

So, the handling of this broken semver range is not actually a breaking change. What changed is that we handle peerDependencies at all, so any broken garbage in a peerDependencies set would have been overlooked in npm v6, and no longer is.

Observe:

$ cat package.json
{
  "dependencies": {
    "react": ">=^16.0.0"
  }
}

$ npm i     # <-- using latest v7 beta
npm ERR! code EINVALIDTAGNAME
npm ERR! Invalid tag name ">=^16.0.0": Tags may not have any characters that encodeURIComponent encodes.

npm ERR! A complete log of this run can be found in:
npm ERR!     /Users/isaacs/.npm/_logs/2020-09-22T21_01_51_852Z-debug.log

$ node ~/dev/npm/cli-v6 i   # <-- my checkout of v6
npm ERR! code EINVALIDTAGNAME
npm ERR! Invalid tag name ">=^16.0.0": Tags may not have any characters that encodeURIComponent encodes.

npm ERR! A complete log of this run can be found in:
npm ERR!     /Users/isaacs/.npm/_logs/2020-09-22T21_01_59_215Z-debug.log

A more extreme example:

$ cat package.json
{
  "peerDependencies": {
    "react": "this is not a valid semver or dist-tag !$@!#$%#@$%!@#$!@#$%"
  }
}

$ npm i
npm ERR! code EINVALIDTAGNAME
npm ERR! Invalid tag name "this is not a valid semver or dist-tag !$@!#$%#@$%!@#$!@#$%": Tags may not have any characters that encodeURIComponent encodes.

npm ERR! A complete log of this run can be found in:
npm ERR!     /Users/isaacs/.npm/_logs/2020-09-22T21_06_30_064Z-debug.log

$ node ~/dev/npm/cli-v6 i
npm notice created a lockfile as package-lock.json. You should commit this file.
npm WARN bad-dep-version requires a peer of react@this is not a valid semver or dist-tag !$@!#$%#@$%!@#$!@#$% but none is installed. You must install peer dependencies yourself.
npm WARN bad-dep-version No description
npm WARN bad-dep-version No repository field.
npm WARN bad-dep-version No license field.

up to date in 0.307s
found 0 vulnerabilities


$ npm i --legacy-peer-deps

up to date in 245ms

found 0 vulnerabilities

I'm tempted to say that this is working as designed. If you want npm v7 to work when peerDependencies contain invalid data, you can use the --legacy-peer-deps switch to tell npm v7 to not look at peerDependencies at all.

The only alternative here would be to catch any invalid data in peerDependencies (but only in peerDependencies), and ignore those peer deps. So then we'd be in a situation where the contract that we install peerDeps is violated.

Another alternative would be that we figure out what >=^16.0.0 means, and add support for that syntax in node-semver. But now we're playing whack-a-mole with whatever unfiltered garbage happened to land in that previously ignored field.

Yes, packages using this dependency will break, but in this case, I don't really know if the alternatives are reasonable. Hopefully the users of react-tooltip can update to the fixed version swiftly.

debel27

comment created time in 5 days

push eventnpm/cli

isaacs

commit sha 82680eb8676c4dc1b87dbf4dea80cae57f002b19

@npmcli/run-script@1.6.0 This updates node-gyp to v7, allowing us to deduplicate a lot of significant dependencies. Fix: #1281 Fix: https://github.com/npm/statusboard/issues/67

view details

push time in 5 days

PR opened npm/cli

@npmcli/run-script@1.6.0

This updates node-gyp to v7, allowing us to deduplicate a lot of significant dependencies.

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

References

<!-- Examples: Related to #0 Depends on #0 Blocked by #0 Fixes #0 Closes #0 -->

+27965 -35996

0 comment

175 changed files

pr created time in 5 days

create barnchnpm/cli

branch : isaacs/node-gyp-7

created branch time in 5 days

push eventnpm/run-script

isaacs

commit sha 4c4f42a392177e41b0eead2989346084d6f92f38

node-gyp@7.1.0

view details

isaacs

commit sha 8794c3268da19437c5e19b8d77d8a9d7c8365bd6

1.6.0

view details

push time in 5 days

created tagnpm/run-script

tagv1.6.0

Run a lifecycle script for a package (descendant of npm-lifecycle)

created time in 5 days

PR closed npm/cli

add ping tests

adds tests for ping command and util

+146 -0

1 comment

2 changed files

nlf

pr closed time in 6 days

pull request commentnpm/cli

add ping tests

LGTM, landing.

nlf

comment created time in 6 days

push eventnpm/cli

Nathan LaFreniere

commit sha 165f4ef4e831a6f802e5d440ce6bbc81484c6095

chore: add tests for ping util and cmd PR-URL: https://github.com/npm/cli/pull/1825 Credit: @nlf Close: #1825 Reviewed-by: @isaacs

view details

push time in 6 days

push eventnpm/arborist

Brian Jenkins

commit sha 383ccfcf8f5a9afc6cb13d41bf59d48e7b17d7b9

Clarify problemEdges logic

view details

Brian Jenkins

commit sha e13ba3bb66a7f7619c3baaa03cc7bccb5201e1ce

Don't automatically install optional peer dependencies Fix: https://github.com/npm/rfcs/pull/224 PR-URL: https://github.com/npm/arborist/pull/138 Credit: @bonkydog Close: #138 Reviewed-by: @isaacs

view details

push time in 9 days

PR closed npm/arborist

Reviewers
Don't automatically install optional peer dependencies

So installing ORMs doesn't install every database driver ever.

References

https://github.com/npm/rfcs/pull/224

+43 -190

0 comment

2 changed files

bonkydog

pr closed time in 9 days

PR closed npm/rfcs

RFC: No auto-install for peerDependencies marked as optional semver:major

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

Summary

Avoid automatically installing peerDependencies marked as optional using peerDependenciesMeta and { "optional": true }.

Motivation

Package authors want to specify supported version ranges of peerDependencies. They also want to set some peers as optional with peerDependenciesMeta and { "optional": true } to avoid automatically installing them when an end-user installs their package.

As an example, let's take a database ORM package. The ORM package could support upwards of a dozen different databases and require an end-user to install the database adapter(s) needed for their project. These database adapters could be huge and could have peerDependencies, postinstall scripts, and other requirements.

It could significantly bloat a project's install time and dependency tree to pull in tons of packages that an end-developer would never use.

Detailed Explanation

  • When a peer dependency is marked as { "optional": true } using peerDependenciesMeta, it should not install automatically.

  • peerDependencies without a peerDependenciesMeta value of { "optional": true } should still install automatically.

Example package.json

{
  "peerDependencies": {
    "react": "^17.0.0"
  },
  "peerDependenciesMeta": {
    "react": {
      "optional": true
    }
  }
}

References

Related to #221 Fixes #221 Closes #221

+120 -0

6 comments

1 changed file

jrylan

pr closed time in 9 days

issue closednpm/cli

[BUG] npm run is broken

<!-- Note: Please search to see if an issue already exists for your problem: https://github.com/npm/cli/issues -->

Current Behavior:

$ npx -qp npm@7.0.0-beta.5 -c 'npm run'
start:webpack-dev-server --open
build:NODE_ENV=production webpack -p

$ npx -qp npm@7.0.0-beta.6 -c 'npm run'
npm timing config:load:defaults Completed in 1ms
...
npm timing npm:load Completed in 25ms
npm run-script <command> [-- <args>]

aliases: run, rum, urn
npm timing npm Completed in 155ms

npm ERR! A complete log of this run can be found in:
npm ERR!     /Users/ahu/.npm/_logs/2020-08-23T00_18_04_815Z-debug.log

Expected Behavior:

$ npx -qp npm@7.0.0-beta.6 -c 'npm run'
start:webpack-dev-server --open
build:NODE_ENV=production webpack -p

Steps To Reproduce:

  1. npx -qp npm@7.0.0-beta.6 -c 'npm run'

Environment:

  • OS: macOS Catalina 10.15.6
  • Node: 12.18.3
  • npm: 6.14.6
  • npx: 6.14.6

closed time in 9 days

ahuglajbclajep

issue commentnpm/cli

[BUG] npm run is broken

It is, but unfortunately npm 6 did not respect this distinction appropriately.

Fixed in latest beta.

ahuglajbclajep

comment created time in 9 days

pull request commentnpm/cli

Add `--strict-peer-deps` option

@ljharb One way to get what you're looking for is to add --strict-peer-deps on your installs. In the scenario described above, that would fail the install.

I think there's a strong case to be made to make that the default in npm v8, especially if the more useful warnings help drive people towards correcting these issues. But the feedback we've been getting is that it's too disruptive right now, and this provides an on-ramp to having that functionality there in the first place.

Another approach which we could consider, but I don't love, is to let the install proceed and do its thing, but still exit with a non-zero status. The hazard there is that it's going to be just as breaking for anyone running installs in CI, and it's a bit weird to exit with an error code if we successfully did exactly what the user asked for.

isaacs

comment created time in 9 days

PR closed npm/cli

add whoami and get-identity tests

Also removed an unused parameter from get-identity, and cleaned up the error message when no registry is specified as well as giving it an error code

+144 -4

0 comment

3 changed files

nlf

pr closed time in 9 days

pull request commentnpm/cli

Add `--strict-peer-deps` option

Yes. If you npm install it might put invalid peer dependencies in place, in cases where no non-conflicting resolution can be found, but a "least bad" resolution can be inferred from the dependency by the package bringing in the conflicted peer deps.

For example:

x -> (y@1, z@2)
y -> PEER(z@1)

If you npm install y@2 and then npm install x, it'll need to have y nested under x, and it'll only be able to get z@2 at a peer (or higher) level, due to x's dependency on it. But, we can infer that z@2 is fine, at least for the ways in which x uses y.

This is a very common situation. So far, every real-world ERESOLVE we've encountered matches this pattern. That's why we went the direction of making --force just accept the "incorrect" inferred resolution. But.... why not just make that the default, rather than making the user apply --force, which has other (possibly unwanted) effects? Why make them run the installation again?

For ls, however, the goal is different. It is there to show you exactly what's out of place or needing investigation. It doesn't exit 0 unless every edge it walks is valid. So, if you have a tree like this:

project
+-- x
|   +-- y@1
|   +-- z@2 (valid for x, not valid for y's peer dep)
+-- y@2

then it will report that the link from node_modules/x/node_modules/y to node_modules/x/node_modules/z is invalid, as its contract requires.

isaacs

comment created time in 10 days

push eventnpm/cli

isaacs

commit sha 1922ef802bd32877716d1eb245e05734302f162d

Add a 'check-coverage' script so we can track towards completion We are targetting 100% test coverage for npm v7 GA. Using a coverage-map, we require that any of the newly created tests fully cover the module that they are testing. However, this has the side effect of _always_ hitting 100% coverage when running 'npm test', even though not all modules are being tested. This adds a new 'load-all' test which, in 'check-coverage' mode, tells nyc to include every file in the project. This also removes the double-run of our tests in CI, where we run once and then immediately run the same exact thing again for Coveralls, and sends the 'check-coverage' output to Coveralls instead.

view details

push time in 10 days

push eventnpm/cli

isaacs

commit sha cdf708c75834e3a54be2351e92126ba689b97344

Add a 'check-coverage' script so we can track towards completion We are targetting 100% test coverage for npm v7 GA. Using a coverage-map, we require that any of the newly created tests fully cover the module that they are testing. However, this has the side effect of _always_ hitting 100% coverage when running 'npm test', even though not all modules are being tested. This adds a new 'load-all' test which, in 'check-coverage' mode, tells nyc to include every file in the project. This also removes the double-run of our tests in CI, where we run once and then immediately run the same exact thing again for Coveralls, and sends the 'check-coverage' output to Coveralls instead.

view details

push time in 10 days

push eventnpm/cli

isaacs

commit sha f874d26bd9af592a6bad8d05464d1cb37d5bdaf4

Add a 'check-coverage' script so we can track towards completion We are targetting 100% test coverage for npm v7 GA. Using a coverage-map, we require that any of the newly created tests fully cover the module that they are testing. However, this has the side effect of _always_ hitting 100% coverage when running 'npm test', even though not all modules are being tested. This adds a new 'load-all' test which, in 'check-coverage' mode, tells nyc to include every file in the project. This also removes the double-run of our tests in CI, where we run once and then immediately run the same exact thing again for Coveralls, and sends the 'check-coverage' output to Coveralls instead.

view details

push time in 10 days

PR opened npm/cli

Reviewers
Add a 'check-coverage' script so we can track towards completion

(Based on https://github.com/npm/cli/pull/1819, land that first.)

We are targetting 100% test coverage for npm v7 GA. Using a coverage-map, we require that any of the newly created tests fully cover the module that they are testing. However, this has the side effect of always hitting 100% coverage when running 'npm test', even though not all modules are being tested.

This adds a new 'load-all' test which, in 'check-coverage' mode, tells nyc to include every file in the project.

This also removes the double-run of our tests in CI, where we run once and then immediately run the same exact thing again for Coveralls, and sends the 'check-coverage' output to Coveralls instead.

+74 -7

0 comment

9 changed files

pr created time in 10 days

create barnchnpm/cli

branch : isaacs/check-coverage

created branch time in 10 days

PR opened npm/cli

Add `--strict-peer-deps` option

This is the CLI portion of https://github.com/npm/arborist/pull/136

+28 -4

0 comment

5 changed files

pr created time in 10 days

create barnchnpm/cli

branch : isaacs/strict-peer-deps

created branch time in 10 days

push eventnpm/cli

isaacs

commit sha 2042c5532277b76fcee295075e74549b84abe664

@npmcli/arborist@0.0.26

view details

push time in 10 days

PR closed npm/cli

fix: npx bin should be executable Bug Release 7.x beta

Is this file still relevant at all? it wasn't touched in a long while but I don't think I've seen anyone complaining about wrong permissions, it seems that these files are cygwin-specific.

Anyways, just opened the PR to raise attention and maybe we can revisit its existence instead. I just noticed it while navigating my local file system since all its peers (bin/npm, bin/npm-cli.js, bin/npx-cli.js) have executable permission but not this one which does not seems right.

+0 -0

1 comment

1 changed file

ruyadorno

pr closed time in 10 days

push eventnpm/cli

isaacs

commit sha f019a248a67e8c46dbe41bf31f4818c5ca2138bf

Remove unused npx binary Close: https://github.com/npm/cli/pull/1792

view details

push time in 10 days

push eventnpm/cli

Nathan LaFreniere

commit sha 940e4a907035e34824db02308a738b3e311ac553

chore: add whoami command tests

view details

Nathan LaFreniere

commit sha 5e780a5f067476c1d207173fc9249faf9eaac0c2

chore: remove unused spec parameter, assign error code

view details

Nathan LaFreniere

commit sha 5ccf22a4a4fdc365595ac9e8ea1b1829e61235eb

chore: add get-identity tests PR-URL: https://github.com/npm/cli/pull/1818 Credit: @nlf Close: #1818 Reviewed-by: @ruyadorno

view details

push time in 10 days

created tagnpm/arborist

tagv0.0.26

npm's tree doctor

created time in 10 days

push eventnpm/arborist

isaacs

commit sha 0a35a362143d7480c5421f3323bbfa4304044f8f

Do not stack overflow on vuln.via cycles

view details

isaacs

commit sha fe0a5f6945366a62fdbe334a8b2c235b8c622fde

Add strictPeerDeps, override ERESOLVE if not true In the overwhelming majority of cases in the wild, a peer dependency conflict that results in an ERESOLVE can be fixed by using the `--force` flag. However, this has other side effects (causing `npm audit fix` to install semver-major fixes, blowing away file collisions, etc.) which might not be desirable. Also, since it's opt-in, it means that users have to run the install twice for something where we're _pretty_ sure what the right course of action is. Let's just make that particular override the default, and reduce most ERESOLVE errors from a crash to a warning. PR-URL: https://github.com/npm/arborist/pull/136 Credit: @isaacs Close: #136 Reviewed-by: @ruyadorno

view details

isaacs

commit sha c427fa96ba4535f09cf625db31216c86dafe459c

0.0.26

view details

push time in 10 days

PR closed npm/arborist

Add strictPeerDeps, override ERESOLVE if not true

In the overwhelming majority of cases in the wild, a peer dependency conflict that results in an ERESOLVE can be fixed by using the --force flag.

However, this has other side effects (causing npm audit fix to install semver-major fixes, blowing away file collisions, etc.) which might not be desirable. Also, since it's opt-in, it means that users have to run the install twice for something where we're pretty sure what the right course of action is.

Let's just make that particular override the default, and reduce most ERESOLVE errors from a crash to a warning.

(Also, a dumb fix for vuln, should probably pull that in regardless of where we land on this.)

cc: @MylesBorins

+362 -7

5 comments

5 changed files

isaacs

pr closed time in 10 days

pull request commentnpm/arborist

Add strictPeerDeps, override ERESOLVE if not true

Yes, we'll be setting strictPeerDeps: true explicitly in npm ls.

isaacs

comment created time in 10 days

PR opened npm/arborist

Reviewers
Add strictPeerDeps, override ERESOLVE if not true

In the overwhelming majority of cases in the wild, a peer dependency conflict that results in an ERESOLVE can be fixed by using the --force flag.

However, this has other side effects (causing npm audit fix to install semver-major fixes, blowing away file collisions, etc.) which might not be desirable. Also, since it's opt-in, it means that users have to run the install twice for something where we're pretty sure what the right course of action is.

Let's just make that particular override the default, and reduce most ERESOLVE errors from a crash to a warning.

(Also, a dumb fix for vuln, should probably pull that in regardless of where we land on this.)

cc: @MylesBorins

+362 -7

0 comment

5 changed files

pr created time in 10 days

create barnchnpm/arborist

branch : isaacs/strict-peer-deps

created branch time in 10 days

issue openednpm/arborist

add trackers for `audit`

Audits can take a while. Let's put some tracker spinners in there so that the user has some idea what's going on.

created time in 10 days

issue closednpm/cli

[BUG] Install of some packages results in Error: `unable to resolve dependency tree`

<!-- Note: Please search to see if an issue already exists for your problem: https://github.com/npm/cli/issues -->

Current Behavior:

<!-- ex. a clear & concise description of what you're experiencing. -->

The installation of some packages results in the Error: unable to resolve dependency tree. This is produced in the file ...@npmcli\arborist\lib\arborist\build-ideal-tree.js when there is no target from check.resolveParent.

If the Installation is run with the flag --legacy-peer-deps it works without Errors.

A Falling Package is e.g. npm i @angular-devkit/build-ng-packagr

Expected Behavior:

<!-- ex. a clear & concise description of what you expected to happen. -->

The error messages should be more meaningful so that the user knows how to solve the problem.

Steps To Reproduce:

  1. Init new npm Project
  2. npm i @angular-devkit/build-ng-packagr

Environment:

  • OS: Windows_NT 10.0.17763
  • Node: v12.18.3
  • npm: v7.0.0-beta.7

closed time in 10 days

boeckMt

issue commentnpm/cli

[BUG] Install of some packages results in Error: `unable to resolve dependency tree`

Closing because we now have more useful error messaging, and can get past most conflicts by using --force.

boeckMt

comment created time in 10 days

issue commentnpm/arborist

warn/throw on mismatched engine/platform all the time, not only for newly added modules

Also: we should track the node/npm version in the package lock, and only run this check (at least in loadVirtual) if it doesn't match the current node/npm versions.

isaacs

comment created time in 10 days

pull request commentnpm/rfcs

RFC for check engines requirements on every install

Implementation issue: https://github.com/npm/arborist/issues/134

markablov

comment created time in 10 days

issue openednpm/arborist

warn/throw on mismatched engine/platform all the time, not only for newly added modules

See https://github.com/npm/rfcs/pull/195

  • Currently we call checkEngine()/checkPlatform() in lib/arborist/reify.js, but only for nodes being added to the tree in reifyNode().
  • Either move that check to loadActual and loadVirtual, so that we can warn when we're initially building the tree, or put it in buildIdealTree since we only care about it when we're going to be modifying stuff? (Ie, should npm ls warn about it? Should npm ls --engines-strict fail entirely and not even show a tree?)
  • Since it's probably too aggressive to fail entirely if a package in the virtual/actual tree has an engine/platform mismatch, we can collect these errors up to the top level, and then have buildIdealTree() decide to throw if there are any engine mismatches and options.enginesStrict is true.

created time in 10 days

push eventnpm/arborist

isaacs

commit sha 65732a7c0bbe69bf6f10038c2dbd3bc214b5207c

bin-links@2.1.4 Avoid trying to clobber bins currently in the process of linking

view details

isaacs

commit sha 3f14dac69eab0051ccc6b211bef457cd418018e4

sort bin link queue for greater determinism Fix: #130

view details

push time in 10 days

issue closednpm/arborist

[BUG] race condition in `node_modules/.bin` linking

If two packages in the tree both try to link to the same bin in node_modules/.bin, then we have a race condition, because it links all bins in parallel without resolving the collisions first. Because local bins are always in "force" mode (effectively trying to clobber whatever's in the way), it is non-deterministic as to which bin gets linked, and can even end up in a state where neither one gets linked, and the bin is just missing.

  • before linking bins in lib/arborist/rebuild.js, ensure that all nodes needing bins to be linked are sorted by name.
  • in https://github.com/npm/bin-links, keep a module-local list of all the bins to be linked, so at least we don't race with ourselves.

closed time in 10 days

isaacs

created tagnpm/bin-links

tagv2.1.4

.bin/ script linker

created time in 11 days

push eventnpm/bin-links

isaacs

commit sha 0d336269938bf47a1532bb8e234e2ac2f8230327

Avoid racing with ourselves First part of fix for https://github.com/npm/arborist/issues/130 If the set of packages are in a predictable order, then calling `binLinks` with multiple packages in sequence should never cause this module to race against itself to create the same bin multiple times in the same place.

view details

isaacs

commit sha 6c8b04413e4b29de1f5cf86e2d74ca5bc472ce7f

2.1.4

view details

push time in 11 days

issue commentnpm/cli

[BUG] `npm i` always pretends it "added 4 packages"

Do you still see this with the latest v7 release? I can't reproduce this one.

targos

comment created time in 11 days

issue closednpm/cli

[BUG] `npm i react@17` never ends

Current Behavior:

Running npm i react@17 in the reproduction project seems to result in an infinite loop and it is not possible to stop the process with CTRL+C.

Expected Behavior:

Like with npm@6, the command should end with an error, because there is no matching version.

Steps To Reproduce:

See https://github.com/targos/npm7-cra#issue-4-npm-i-react17-never-ends

Environment:

  • OS: CentOS 8, Windows 10
  • Node: 14.11.0
  • npm: 7.0.0-beta.11

closed time in 11 days

targos

issue commentnpm/cli

[BUG] `npm i react@17` never ends

Fixed by npm/arborist@789f9bc, will be in next v7 release.

targos

comment created time in 11 days

issue closednpm/cli

[BUG] `npm ci` prints an error without context

Current Behavior:

Running npm ci prints npm WARN Error: Unsupported engine but there is no other information about the error (which package it comes from, for example).

Expected Behavior:

There should be more information printed about the error, to allow fixing it.

Steps To Reproduce:

See https://github.com/targos/npm7-cra#issue-2-npm-ci-prints-an-error-without-context

Environment:

  • OS: CentOS 8, Windows 10
  • Node: 14.11.0
  • npm: 7.0.0-beta.11

closed time in 11 days

targos

issue commentnpm/cli

[BUG] `npm ci` prints an error without context

Fixed by npm/arborist@0edf2ed, will be in next v7 release.

targos

comment created time in 11 days

issue closednpm/cli

[BUG] `npm ci` changes package.json

Current Behavior:

Running npm ci updates the dependencies in package.json (key ordering).

Expected Behavior:

npm ci should either error or ignore the wrong ordering. I expect only npm install to modify files like package.json or package-lock.json.

Steps To Reproduce:

See https://github.com/targos/npm7-cra#issue-1-npm-ci-changes-packagejson

Environment:

  • OS: CentOS 8, Windows 10
  • Node: 14.11.0
  • npm: 7.0.0-beta.11 (note that this did not happen with v70.0-beta.10)

closed time in 11 days

targos

issue commentnpm/cli

[BUG] `npm ci` changes package.json

Fixed by 24f3a5448

Sorry, didn't notice you'd posted issues, so the ref in the commit is pointing at your repro repo. Thanks!

targos

comment created time in 11 days

push eventnpm/arborist

isaacs

commit sha 789f9bc8259dbe95486b0a8da2d8c23216276bff

Do not try to re-resolve failed nodes forever Via: https://github.com/targos/npm7-cra#issue-4-npm-i-react17-never-ends

view details

isaacs

commit sha 0edf2ed0bf7b210d249ed09e6bc8f5bf265c8393

Log cleanup and engine mismatches more usefully Via: https://github.com/targos/npm7-cra#issue-2-npm-ci-prints-an-error-without-context

view details

push time in 11 days

push eventnpm/cli

isaacs

commit sha 24f3a5448f021ad603046dfb9fd97ed66bd63bba

npm ci should never save package.json or lockfile Via: https://github.com/targos/npm7-cra#issue-1-npm-ci-changes-packagejson

view details

push time in 11 days

push eventnpm/cli

isaacs

commit sha ecd42ce56e1b51b583439bc7b30d1fdce98e4665

docs: fix scoped package names in changelog

view details

push time in 11 days

issue commentnpm/rfcs

[RRFC] npm audit <package> for a not yet installed package

there may be a package named "fix" Ah yes, there is: https://www.npmjs.com/package/fix

Christian24

comment created time in 11 days

issue commentnpm/rfcs

[RRFC] npm audit <package> for a not yet installed package

  • Should be a subcommand (ie, there may be a package named "fix")
  • Maybe attach this info to npm view?
  • Getting the full advisory set for the specified package and its deps is a little more work, but probably way more useful.
  • This is semver-minor, can come in a 7.x release.
  • much easier if we restrict it to using the new bulk advisory endpoint (since it won't require generating a complete package-lock tree shape, though we'd have to do that anyway to test deps and metavulns, so maybe not much of an issue)
Christian24

comment created time in 11 days

pull request commentnpm/rfcs

RFC: Add `npm-app-id` HTTP header

Leaning towards "add headers list to config", and then we can later add an RFC to put a npm-app-id header from the registry is saved to ./.npmrc by default.

Mykyta

comment created time in 11 days

pull request commentnpm/rfcs

RFC: Add `npm-app-id` HTTP header

Other options to explore, discussed in 2020-09-16 RFC call:

{
  "headers": {
    "app-id": "call it headers instead of metadata"
  }
}
{
  "appId": "top-level field"
}
; project-level .npmrc
headers[]="npm-app-id: a config value"
headers[]="Authorization: custom-thing whatever idk"
Mykyta

comment created time in 11 days

PullRequestReviewEvent

push eventnpm/arborist

isaacs

commit sha b9f6dcd553ebbb4c689370964d5e2805a6788242

Use @npmcli/metavuln-calculator for faster audits This makes the AuditReport calculation around 40% faster in the cold cache state, and anywhere from 90% to 99% faster with a warm cache. It also sets the stage for the capability of doing audits without hitting the registry, and potentially avoiding known-vulnerable package versions if they've been previously marked and cached as vulnerable. (This additional functionality is not implemented in this change, but it's something we can do in the future.) One impact is that the `Vuln` class now has an `advisories` set, as well as a `via` set. `vuln.advisories` is a set of advisories created by the metavuln-calculator, which can represent either actual advisories or metavulns. The `via` set is a list of Vuln objects _only_, so that we can track fixes and report on them comprehensively. Fix: https://github.com/npm/arborist/issues/109

view details

push time in 11 days

Pull request review commentnpm/arborist

Use @npmcli/metavuln-calculator for faster audits

 class AuditReport extends Map {    async run () {     this.report = await this[_getReport]()-    if (this.report) {+    if (this.report)       await this[_init]()-      await this[_processDeps]()-    }     return this   } +  isVulnerable (node) {+    const vuln = this.get(node.package.name)+    return !!(vuln && vuln.isVulnerable(node))+  }+   async [_init] () {     process.emit('time', 'auditReport:init')      const promises = []     for (const [name, advisories] of Object.entries(this.report)) {       for (const advisory of advisories) {-        const { vulnerable_versions: range } = advisory-        promises.push(this[_addVulnerability](name, range, advisory))+        //const { vulnerable_versions: range } = advisory+        promises.push(this.calculator.calculate(name, advisory))       }     }-    await Promise.all(promises) -    process.emit('timeEnd', 'auditReport:init')-  }+    // now the advisories are calculated with a set of versions+    // and the packument.  turn them into our style of vuln objects+    // which also have the affected nodes, and also create entries+    // for all the metavulns that we find from dependents.+    const advisories = new Set(await Promise.all(promises))+    const seen = new Set()+    for (const advisory of advisories) {+      const { name, range } = advisory++      // don't flag the exact same name/range more than once+      // adding multiple advisories with the same range is fine, but no+      // need to search for nodes we already would have added.+      const k = `${name}@${range}`+      if (seen.has(k)) {+        continue+      }+      seen.add(k) -  // for each node P-  //  for each vulnerable dep Q-  //    pickManifest(Q, P's dep on Q, {avoid})-  //    if resulting version is vunlerable, then P@version is vulnerable-  //      find all versions of P depending on unsafe Q-  async [_processDeps] () {-    process.emit('time', 'auditReport:process')-    for (const p of this[_vulnDependents]) {-      await this[_processDependent](p)-    }-    process.emit('timeEnd', 'auditReport:process')-  }+      const vuln = this.get(name) || new Vuln({ name, advisory })+      if (this.has(name))+        vuln.addAdvisory(advisory)+      super.set(name, vuln)

this.set throws an error, because you're not supposed to use report.set() directly. Calling super.set() calls the method from the Map class (which this extends).

isaacs

comment created time in 11 days

PullRequestReviewEvent

Pull request review commentnpm/arborist

Use @npmcli/metavuln-calculator for faster audits

 class AuditReport extends Map {    async run () {     this.report = await this[_getReport]()-    if (this.report) {+    if (this.report)       await this[_init]()-      await this[_processDeps]()-    }     return this   } +  isVulnerable (node) {+    const vuln = this.get(node.package.name)+    return !!(vuln && vuln.isVulnerable(node))+  }+   async [_init] () {     process.emit('time', 'auditReport:init')      const promises = []     for (const [name, advisories] of Object.entries(this.report)) {       for (const advisory of advisories) {-        const { vulnerable_versions: range } = advisory-        promises.push(this[_addVulnerability](name, range, advisory))+        //const { vulnerable_versions: range } = advisory

Hmm, yeah, looks like scar tissue.

isaacs

comment created time in 11 days

PullRequestReviewEvent

PR opened npm/arborist

Reviewers
Use @npmcli/metavuln-calculator for faster audits

This makes the AuditReport calculation around 40% faster in the cold cache state, and anywhere from 90% to 99% faster with a warm cache.

It also sets the stage for the capability of doing audits without hitting the registry, and potentially avoiding known-vulnerable package versions if they've been previously marked and cached as vulnerable. (This additional functionality is not implemented in this change, but it's something we can do in the future.)

One impact is that the Vuln class now has an advisories set, as well as a via set. vuln.advisories is a set of advisories created by the metavuln-calculator, which can represent either actual advisories or metavulns. The via set is a list of Vuln objects only, so that we can track fixes and report on them comprehensively.

Fix: https://github.com/npm/arborist/issues/109

+2144 -2328

0 comment

15 changed files

pr created time in 11 days

push eventnpm/arborist

isaacs

commit sha c181417c66c2d73eb1e8b9c9f69e1b3ad1825366

Use @npmcli/metavuln-calculator for faster audits This makes the AuditReport calculation around 40% faster in the cold cache state, and anywhere from 90% to 99% faster with a warm cache. It also sets the stage for the capability of doing audits without hitting the registry, and potentially avoiding known-vulnerable package versions if they've been previously marked and cached as vulnerable. (This additional functionality is not implemented in this change, but it's something we can do in the future.) One impact is that the `Vuln` class now has an `advisories` set, as well as a `via` set. `vuln.advisories` is a set of advisories created by the metavuln-calculator, which can represent either actual advisories or metavulns. The `via` set is a list of Vuln objects _only_, so that we can track fixes and report on them comprehensively. Fix: https://github.com/npm/arborist/issues/109

view details

push time in 11 days

create barnchnpm/arborist

branch : isaacs/faster-audit

created branch time in 11 days

push eventnpm/arborist

Ruy Adorno

commit sha ba2b5dcc7b463e028f429d515e9e761c2b5a1b29

fix: always parse spec from cwd Always parse specs from added deps using the cwd as reference. Also refactored lib/add-rm-pkg-deps.js to only used rawSpec now that build-ideal-tree does the heavy lifting of parsing relative paths. PR-URL: https://github.com/npm/arborist/pull/132 Credit: @ruyadorno Close: #132 Reviewed-by: @isaacs

view details

isaacs

commit sha 013dac4e1ecbea717d91c99421c9de192ca399ea

0.0.24

view details

push time in 11 days

PR closed npm/arborist

fix: always parse spec from cwd

Always parse specs from added deps using the cwd as reference. Also refactored lib/add-rm-pkg-deps.js to only used rawSpec now that build-ideal-tree does the heavy lifting of parsing relative paths.

+37 -47

0 comment

4 changed files

ruyadorno

pr closed time in 11 days

created tagnpm/arborist

tagv0.0.24

npm's tree doctor

created time in 11 days

push eventnpm/metavuln-calculator

isaacs

commit sha 936732981fc0a1bf9bbb5fbed539fdc89c0c8ba4

Move some Calculator fields to private

view details

isaacs

commit sha ab51202876cd50d73bf32a91aa4961b20c75b1c8

Memoize more, check versions more efficiently Memoize the calculate() call, so that we return the same promise/vuln object if called multiple times about the same source advisory. Instead of calling npm-pick-manifest, just walk the list of versions and jump out when we hit the first one that is a non-vulnerable match to the spec.

view details

isaacs

commit sha c89bcc9582eaa357fa25ba99f6d8f68ed93023b0

Rename 'vuln' to 'advisory' It's only a 'vulnerability' if it's in an actual project. At the level that this module operates, they're still just 'advisories'.

view details

isaacs

commit sha ac5adeaf8b179bf056c196fa60ed97f84a319ad5

bug fixes for edge cases found during arborist integration

view details

isaacs

commit sha 1e1421527e662c2b1b8c38fcbbde3e014b518e8d

update docs with accurate cache key info

view details

isaacs

commit sha c9a9a21c6dede0e819ee053ab80d271115b22682

1.0.0

view details

push time in 11 days

created tagnpm/metavuln-calculator

tagv1.0.0

Calculate meta-vulnerabilities from package security advisories

created time in 11 days

PullRequestReviewEvent

Pull request review commentnpm/arborist

fix: follow symlinks on build-ideal-tree add

 module.exports = cls => class IdealTreeBuilder extends cls {     this[_linkNodes] = new Set()     this[_manifests] = new Map()     this[_peerConflict] = null++    // caches for cached realpath calls+    const cwd = process.cwd()+    // assume that the cwd is real enough for our purposes+    this[_rpcache] = this[_rpcache] || new Map([[ cwd, cwd ]])+    this[_stcache] = this[_stcache] || new Map()

just delete these two lines, no need to re-initialize since ActualLoader does it.

ruyadorno

comment created time in 12 days

PullRequestReviewEvent

Pull request review commentnpm/arborist

fix: follow symlinks on build-ideal-tree add

 module.exports = cls => class IdealTreeBuilder extends cls {     return Promise.all(add.map(s => {       // in global mode, `npm i foo.tgz` needs to be resolved from       // the current working dir, NOT /usr/local/lib!-      const spec = npa(s, this[_global] ? process.cwd() : this.path)-      // if it's just @'' then we reload whatever's there, or get latest-      // if it's an explicit tag, we need to install that specific tag version-      const isTag = spec.rawSpec && spec.type === 'tag'-      return spec.name && !isTag ? spec : pacote.manifest(spec).then(mani => {-        // if it's a tag type, then we need to run it down to an actual version-        if (isTag)-          return npa(`${mani.name}@${mani.version}`)--        spec.name = mani.name-        return spec-      })+      const currpath = this[_global] ? process.cwd() : this.path

We can land on a separate commit, but ought to get it fixed, may as well pull in with this changeset.

ruyadorno

comment created time in 13 days

Pull request review commentnpm/arborist

fix: follow symlinks on build-ideal-tree add

 module.exports = cls => class IdealTreeBuilder extends cls {     this[_linkNodes] = new Set()     this[_manifests] = new Map()     this[_peerConflict] = null++    // caches for cached realpath calls+    const cwd = process.cwd()+    // assume that the cwd is real enough for our purposes+    this[_rpcache] = new Map([[ cwd, cwd ]])+    this[_stcache] = new Map()

Same for statCache

ruyadorno

comment created time in 13 days

Pull request review commentnpm/arborist

fix: follow symlinks on build-ideal-tree add

 module.exports = cls => class IdealTreeBuilder extends cls {     this[_linkNodes] = new Set()     this[_manifests] = new Map()     this[_peerConflict] = null++    // caches for cached realpath calls+    const cwd = process.cwd()+    // assume that the cwd is real enough for our purposes+    this[_rpcache] = new Map([[ cwd, cwd ]])

Since we already have a realpath cache on the Arborist object for use by Arborist.loadActual(), it'd be better for both of them to use const _rpcache = Symbol.for('realpathCache'), and only have one of them initialize it. Otherwise we're doing double work and not caching as efficiently as we could be.

ruyadorno

comment created time in 13 days

PullRequestReviewEvent
PullRequestReviewEvent

Pull request review commentnpm/arborist

fix: follow symlinks on build-ideal-tree add

 const addSingle = ({pkg, spec, saveBundle, saveType, path}) => {   pkg[type] = pkg[type] || {}   if (rawSpec !== '' || pkg[type][name] === undefined) {     // if we're in global mode, file specs are based on cwd, not arb path

Is this comment still valid? Should be for all file specs, not just global ones.

ruyadorno

comment created time in 13 days

PullRequestReviewEvent
PullRequestReviewEvent

issue openednpm/arborist

[BUG] race condition in `node_modules/.bin` linking

If two packages in the tree both try to link to the same bin in node_modules/.bin, then we have a race condition, because it links all bins in parallel without resolving the collisions first. Because local bins are always in "force" mode (effectively trying to clobber whatever's in the way), it is non-deterministic as to which bin gets linked, and can even end up in a state where neither one gets linked, and the bin is just missing.

  • before linking bins in lib/arborist/rebuild.js, ensure that all nodes needing bins to be linked are sorted by name.
  • in https://github.com/npm/bin-links, keep a module-local list of all the bins to be linked, so at least we don't race with ourselves.

created time in 15 days

push eventnpm/metavuln-calculator

isaacs

commit sha 91634a13e4a6116e35783e05009d31497e204253

coverage map

view details

isaacs

commit sha 335f4d5ccfd4c189f3709246db11b47f35ffcf90

packaging

view details

isaacs

commit sha 194eeb34a2bff212482736268fe0e8e54f78173c

the Vuln (internal) class

view details

isaacs

commit sha 442912062cbe643a8a9dd717f9f622323bf3d84a

add option to pass dep spec to vuln.testVersion This is important for cases where the dependency specifier is not possible to find from the packument, eg for deps not in the registry.

view details

isaacs

commit sha e60f8ca84d5aed805a8f0ac760982767e3b1b75d

update readme with Vuln class and public method

view details

isaacs

commit sha c40ec5c5c0401f6e3648f73d61a1b2cbc23173f2

tests

view details

isaacs

commit sha 5d36298c081be40e6a8bde1836f003384669aa48

codes

view details

isaacs

commit sha e812c6a98373ef22738b03524ffc750364edd90f

add require-inject dev dependency

view details

push time in 15 days

more