profile
viewpoint
Ruy Adorno ruyadorno @npm Montreal, Canada http://ruyadorno.com Open Source Software Developer @npm Immigrant to beautiful Canada 🇨🇦 Node.js • JavaScript • UI/UX • CLI

millermedeiros/esformatter 952

ECMAScript code beautifier/formatter

opensourcecities/montreal 64

A directory of companies, people, and projects that are Open Source and from Montréal.

millermedeiros/disparity 45

colorized string diff (char or unified) ideal for text/code that spans through multiple lines

marloscarmo/data-metrics 33

data-metrics is a data-attribute that allows you to easily track Google Analytics metrics in your HTML page.

ruyadorno/angular-simple-slider 15

An AngularJS directive providing a simple slider functionality

ruyadorno/checkbower 13

Validates your bower.json files

ruyadorno/clean-dir 9

Command line util to clean a directory

rosaneviotti/rosaneviotti.github.io 2

My personal portfolio

ruyadorno/checkgituser 1

Checks a folder to find .git/config files without an [user] field declared

npm/content-type-to-language-name 0

Maps a list of content types to a list of language names

startedbengl/sbffi

started time in 6 hours

delete branch npm/arborist

delete branch : isaacs/easier-add

delete time in 7 hours

delete branch npm/arborist

delete branch : isaacs/timing

delete time in 7 hours

delete branch npm/arborist

delete branch : mikemimik/feature/expose-diff

delete time in 7 hours

delete branch npm/arborist

delete branch : mikemimik/feature/catch-failed-write

delete time in 7 hours

push eventnpm/arborist

isaacs

commit sha 2d94b28402a2f8868e934b812257ea99eaad643b

add Arborist.rebuild() This refactors reify() to move bin linking and script running into the rebuild() method, and exposes it for use in 'npm rebuild' PR-URL: https://github.com/npm/arborist/pull/83 Credit: @isaacs Close: #83 Reviewed-by: @ruyadorno

view details

push time in 3 days

PR closed npm/arborist

add Arborist.rebuild()

Stacks on top of #81, land that first.

This refactors reify() to move bin linking and script running into the rebuild() method, and exposes it for use in 'npm rebuild'

+2115 -231

0 comment

59 changed files

isaacs

pr closed time in 3 days

push eventnpm/arborist

isaacs

commit sha 7e92f6cea0e9ea8cd90aa71dffe2a17d86486a17

Refactor the Arborist class mixin stack There's no reason why these mixins have to stack on one another in the definition or extend one another. We only ever use the Arborist class as a fully-assembled thing, so it's fine to just throw them all in a list and call it a day.

view details

isaacs

commit sha 9efb437e542adfa78a9e58dff79746d9e20ba615

fix: Handle tarball dependencies properly For 'file:' deps (whether directory or tarball type), Node.resolved is always absolute. It was initially set up to be relative to the node path, because it had to be stashed back to package.json. But, then we got rid of that approach in favor of a more comprehensive lockfile, and so the added complexity of constantly re-evaluating the resolved value as the node moves around serves no purpose. This relative linking also _wasn't_ being handled properly in tarball dependencies, resulting in attempting to fetch a tarball from the wrong location, relative to the dependent's directory in node_modules, rather than where it should be found. Since we never store Node.resolved anywhere, there's no need for it to be portable, and the portability had a bug anyway. *Shrinkwrap* files *do* have to be portable, so the paths get relativized (and resolved) going into and out of lockfiles. But that's much simpler. Tarball dependencies are more consistently handled, and now that the Node.resolved value is absolute and predictable, it's easier to get that right. Tarball dependencies are properly regarded as a valid dependency resolution, provided that they come from the same target file. It's still a bit of a crapshoot when we get legacy install trees, but at least now we're not throwing out package._resolved when we load the manifest from pacote directly. The added test case installs a tarball dependency which depends on two other tarballs: 1 in its own containing folder, and another outside of its folder. (This exact situation was a thorn in npm's side for most of 6.x, and might still be in some cases.) PR-URL: https://github.com/npm/arborist/pull/81 Credit: @isaacs Close: #81 Reviewed-by: @ruyadorno

view details

push time in 3 days

PR closed npm/arborist

fix: Handle tarball dependencies properly

Stacks on #80, land that first.

For 'file:' deps (whether directory or tarball type), Node.resolved is always absolute. It was initially set up to be relative to the node path, because it had to be stashed back to package.json. But, then we got rid of that approach in favor of a more comprehensive lockfile, and so the added complexity of constantly re-evaluating the resolved value as the node moves around serves no purpose.

This relative linking also wasn't being handled properly in tarball dependencies, resulting in attempting to fetch a tarball from the wrong location, relative to the dependent's directory in node_modules, rather than where it should be found. Since we never store Node.resolved anywhere, there's no need for it to be portable, and the portability had a bug anyway.

Shrinkwrap files do have to be portable, so the paths get relativized (and resolved) going into and out of lockfiles. But that's much simpler.

Tarball dependencies are more consistently handled, and now that the Node.resolved value is absolute and predictable, it's easier to get that right.

Tarball dependencies are properly regarded as a valid dependency resolution, provided that they come from the same target file. It's still a bit of a crapshoot when we get legacy install trees, but at least now we're not throwing out package._resolved when we load the manifest from pacote directly.

The added test case installs a tarball dependency which depends on two other tarballs: 1 in its own containing folder, and another outside of its folder. (This exact situation was a thorn in npm's side for most of 6.x, and might still be in some cases.)

+431 -82

0 comment

31 changed files

isaacs

pr closed time in 3 days

Pull request review commentnpm/arborist

fix: Handle tarball dependencies properly

 Node { } ` +exports[`test/arborist/build-ideal-tree.js TAP tarball deps with transitive tarball deps > expect resolving Promise 1`] = `+Node {+  "children": Map {+    "@isaacs/testing-file-transitive-a" => Node {+      "edgesIn": Set {+        Edge {+          "from": "",+          "name": "@isaacs/testing-file-transitive-a",+          "spec": "file:testing-file-transitive-a/isaacs-testing-file-transitive-a-1.0.0.tgz",+          "type": "prod",+        },+      },+      "edgesOut": Map {+        "@isaacs/testing-file-transitive-b" => Edge {+          "name": "@isaacs/testing-file-transitive-b",+          "spec": "file:../testing-file-transitive-b/isaacs-testing-file-transitive-b-1.0.0.tgz",+          "to": "node_modules/@isaacs/testing-file-transitive-b",+          "type": "prod",+        },+        "@isaacs/testing-file-transitive-c" => Edge {+          "name": "@isaacs/testing-file-transitive-c",+          "spec": "file:./c/isaacs-testing-file-transitive-c-1.0.0.tgz",+          "to": "node_modules/@isaacs/testing-file-transitive-c",+          "type": "prod",+        },+      },+      "location": "node_modules/@isaacs/testing-file-transitive-a",+      "name": "@isaacs/testing-file-transitive-a",+      "resolved": "file:{CWD}/test/fixtures/tarball-dependencies/testing-file-transitive-a/isaacs-testing-file-transitive-a-1.0.0.tgz",+    },+    "@isaacs/testing-file-transitive-b" => Node {+      "edgesIn": Set {+        Edge {+          "from": "node_modules/@isaacs/testing-file-transitive-a",+          "name": "@isaacs/testing-file-transitive-b",+          "spec": "file:../testing-file-transitive-b/isaacs-testing-file-transitive-b-1.0.0.tgz",+          "type": "prod",+        },+      },+      "location": "node_modules/@isaacs/testing-file-transitive-b",+      "name": "@isaacs/testing-file-transitive-b",+      "resolved": "file:{CWD}/test/fixtures/tarball-dependencies/testing-file-transitive-b/isaacs-testing-file-transitive-b-1.0.0.tgz",+    },+    "@isaacs/testing-file-transitive-c" => Node {+      "edgesIn": Set {+        Edge {+          "from": "node_modules/@isaacs/testing-file-transitive-a",+          "name": "@isaacs/testing-file-transitive-c",+          "spec": "file:./c/isaacs-testing-file-transitive-c-1.0.0.tgz",+          "type": "prod",+        },+      },+      "location": "node_modules/@isaacs/testing-file-transitive-c",+      "name": "@isaacs/testing-file-transitive-c",+      "resolved": "file:{CWD}/test/fixtures/tarball-dependencies/testing-file-transitive-a/c/isaacs-testing-file-transitive-c-1.0.0.tgz",+    },+  },+  "edgesOut": Map {+    "@isaacs/testing-file-transitive-a" => Edge {+      "name": "@isaacs/testing-file-transitive-a",+      "spec": "file:testing-file-transitive-a/isaacs-testing-file-transitive-a-1.0.0.tgz",+      "to": "node_modules/@isaacs/testing-file-transitive-a",+      "type": "prod",+    },+  },+  "location": "",+  "name": "tarball-dependencies",+  "resolved": null,+}+`+

I see! I think one piece of information I skipped and realized later is that these spec values are from edges, so in reality it's just whatever was declared there in this fixture deps 😊

isaacs

comment created time in 3 days

Pull request review commentnpm/arborist

fix: Handle tarball dependencies properly

 Node { } ` +exports[`test/arborist/build-ideal-tree.js TAP tarball deps with transitive tarball deps > expect resolving Promise 1`] = `+Node {+  "children": Map {+    "@isaacs/testing-file-transitive-a" => Node {+      "edgesIn": Set {+        Edge {+          "from": "",+          "name": "@isaacs/testing-file-transitive-a",+          "spec": "file:testing-file-transitive-a/isaacs-testing-file-transitive-a-1.0.0.tgz",+          "type": "prod",+        },+      },+      "edgesOut": Map {+        "@isaacs/testing-file-transitive-b" => Edge {+          "name": "@isaacs/testing-file-transitive-b",+          "spec": "file:../testing-file-transitive-b/isaacs-testing-file-transitive-b-1.0.0.tgz",+          "to": "node_modules/@isaacs/testing-file-transitive-b",+          "type": "prod",+        },+        "@isaacs/testing-file-transitive-c" => Edge {+          "name": "@isaacs/testing-file-transitive-c",+          "spec": "file:./c/isaacs-testing-file-transitive-c-1.0.0.tgz",+          "to": "node_modules/@isaacs/testing-file-transitive-c",+          "type": "prod",+        },+      },+      "location": "node_modules/@isaacs/testing-file-transitive-a",+      "name": "@isaacs/testing-file-transitive-a",+      "resolved": "file:{CWD}/test/fixtures/tarball-dependencies/testing-file-transitive-a/isaacs-testing-file-transitive-a-1.0.0.tgz",+    },+    "@isaacs/testing-file-transitive-b" => Node {+      "edgesIn": Set {+        Edge {+          "from": "node_modules/@isaacs/testing-file-transitive-a",+          "name": "@isaacs/testing-file-transitive-b",+          "spec": "file:../testing-file-transitive-b/isaacs-testing-file-transitive-b-1.0.0.tgz",+          "type": "prod",+        },+      },+      "location": "node_modules/@isaacs/testing-file-transitive-b",+      "name": "@isaacs/testing-file-transitive-b",+      "resolved": "file:{CWD}/test/fixtures/tarball-dependencies/testing-file-transitive-b/isaacs-testing-file-transitive-b-1.0.0.tgz",+    },+    "@isaacs/testing-file-transitive-c" => Node {+      "edgesIn": Set {+        Edge {+          "from": "node_modules/@isaacs/testing-file-transitive-a",+          "name": "@isaacs/testing-file-transitive-c",+          "spec": "file:./c/isaacs-testing-file-transitive-c-1.0.0.tgz",+          "type": "prod",+        },+      },+      "location": "node_modules/@isaacs/testing-file-transitive-c",+      "name": "@isaacs/testing-file-transitive-c",+      "resolved": "file:{CWD}/test/fixtures/tarball-dependencies/testing-file-transitive-a/c/isaacs-testing-file-transitive-c-1.0.0.tgz",+    },+  },+  "edgesOut": Map {+    "@isaacs/testing-file-transitive-a" => Edge {+      "name": "@isaacs/testing-file-transitive-a",+      "spec": "file:testing-file-transitive-a/isaacs-testing-file-transitive-a-1.0.0.tgz",+      "to": "node_modules/@isaacs/testing-file-transitive-a",+      "type": "prod",+    },+  },+  "location": "",+  "name": "tarball-dependencies",+  "resolved": null,+}+`+

just curious about the resolved spec values that varies across this snapshot, some of them point at file:testing-file-transitive* others to file:../testing-file-transitive*, some other to file:./c/

took a quick look at the fixtures and while the file:./c/ path seems to make sense since that's a nested folder - I'm quite confused to why we then have file:testing-file-transitive-a/ and file:../testing-file-transitive-b/, it seems to me it would have to be either file:./ (for transitive-a) and then file:../testing-file-transitive-b/ or file:../testing-file-transitive-a/ and file:../testing-file-transitive-b/

isaacs

comment created time in 3 days

push eventnpm/arborist

isaacs

commit sha 6ea73de40aaa362cc32cc6911e58e459ea27c8bf

test: add proper caching where it was missing

view details

isaacs

commit sha d4ab8b3c273f29e555bfc2a0ac5fb59d8aaa2ef5

Support rebuildBundle: false Re: https://github.com/npm/arborist/issues/46 PR-URL: https://github.com/npm/arborist/pull/80 Credit: @isaacs Close: #80 Reviewed-by: @ruyadorno

view details

push time in 3 days

PR closed npm/arborist

Add support for rebuildBundle: false

stacks on top of #78, land that first.

+1068 -264

0 comment

26 changed files

isaacs

pr closed time in 3 days

PR closed npm/arborist

Add support for the packageLockOnly config

This tells reify() to just generate the ideal tree and write package-lock.json and package.json, but do nothing else.

Re #46

+796 -231

0 comment

14 changed files

isaacs

pr closed time in 3 days

push eventnpm/arborist

isaacs

commit sha ce51fc962efdcae90c8deda5f1248e041abefd32

Add support for the packageLockOnly config This tells reify() to just generate the ideal tree and write package-lock.json and package.json, but do nothing else. Re #46 PR-URL: https://github.com/npm/arborist/pull/78 Credit: @isaacs Close: #78 Reviewed-by: @ruyadorno

view details

push time in 3 days

push eventnpm/arborist

isaacs

commit sha 4f8c6c9541bb4266365a67f4f213e853a88d23de

Fully update metadata/location when moving roots There were some cases, especially when moving fsChildren from one root to another, where the node.location would not be updated in the correct sequence, resulting in the metadata being incorrect or missing, and node.location being out of sync with node.path and node.root.path. Discovered while adding functionality for #72

view details

isaacs

commit sha 92176417f6f22b1998833e306c5104310a293bcc

Add loadActual({ root: Node }) to compose trees Implementation for #72

view details

isaacs

commit sha 89fb80fa9427b6ac112e09e41dafc106c8dc4408

loadActual: cleanup code using async/await

view details

isaacs

commit sha 9b979840479216c874a3967659f692823eb38b49

calcDepFlags: add 'resetRoot' flag to tell it to not do that When we call loadActual to load bundle deps, we do NOT want to reset all the dev/optional/etc flags.

view details

isaacs

commit sha 5ee0d16502d0e9bd35985d0d2b075f6158d1ca28

loadActual: add transplantFilter method to filter what gets transplanted

view details

isaacs

commit sha 32747a258f46fbf1835fa16b381b5f2b31c4f263

reify: replace load-bundle-deps module with loadActual({root}) This makes it so that we get proper dep flags in bundled deps! Win!

view details

isaacs

commit sha 5fac0af5a7d1f821c07c610e5a81aa4d67afc9b2

buildIdeal: replace load-bundle-deps module with loadActual({root})

view details

isaacs

commit sha ffe57201350c79eedd57fbec4f4a09670f72ddf1

remove unused load-bundle-deps module PR-URL: https://github.com/npm/arborist/pull/77 Credit: @isaacs Close: #77 Reviewed-by: @ruyadorno

view details

push time in 3 days

PR closed npm/arborist

Add loadActual({ root: node })

Fix #72

This also uncovered a few lurking bugs around how we update metadata when transplanting nodes, and how dep flags (dev/optional/etc) were being set on installed bundle dependencies.

+613 -213

0 comment

14 changed files

isaacs

pr closed time in 3 days

created tagnpm/disparity-colors

tagv1.0.0

Colorizes unified diff output

created time in 3 days

create barnchnpm/disparity-colors

branch : master

created branch time in 3 days

created repositorynpm/disparity-colors

Colorizes unified diff output

created time in 3 days

push eventnpm/map-workspaces

Ruy Adorno

commit sha 633302eca80f9b4e7d2bd4750a85dbe672cea62d

chore: add engines info

view details

push time in 4 days

Pull request review commentnpm/rfcs

npm audit resolve

+# Interactive audit resolver++## Summary++This proposal is for adding means for a human to resolve issues from `npm audit` and interactively make decisions about each issue. Available as `npm audit resolve` command.++Features:+- Remember the resolutions and allow them to affect `npm audit` behavior.+- Decision options include 'ignore', 'remind later', 'fix', 'remove'.+- Allow tracking who resolved an issue and when using git history.+++## Motivation++At times, running `npm audit fix` won't fix all audit issues. Fixes might not be available or the user might not want to apply some of them, eg. major version updates or build/test dependencies.++It should be possible to make `npm audit` a step in a CI pipeline to go red every time a new vulnerability affects the project. Managing security of dependencies should be quick to update, effective, easy to audit over time and secure in itself.++For that, the user needs a new tool which makes addressing issues one by one convenient even across a whole ecosystem of projects.++## Detailed Explanation++`npm audit resolve` runs audit and iterates over all actions from the output with a prompt for a decision on each. +If fix is available, it's offered as one of the options to proceed. Other options include: ignore, remind later and delete.++All decisions are stored in `audit-resolve.json` file as key-value, where key is `${advisory id}|${dependency path}` and value is:++```js+{+  decision: "fix|ignore|postpone",+  madeAt: <timestamp of when the decision was made>+}+```++`npm audit` reads `audit-resolve.json` and respects the resolution (ignores ignored issues, ignores issues postponed to a date in the future)++### resolutions+- **fix** runs the fix proposed in audit action and marks the issue as fixed in `audit-resolve.json`. On each subsequent run of `npm audit resolve` if the issue comes up again, the user is also warned that the problem was supposed to be fixed already.+- **ignore** marks the issue as ignored and `npm audit` will no longer fail because of it (but should display a single line warning about the issue being ignored). If a new vulnerability is found in the same dependency, it does not get ignored. If another dependency is installed with the same vulnerability advisory id it is not ignored. If the same package is installed as a dependency to another dependency (different path) it is not ignored.+- **postpone** marks the issue as postponed to a timestamp 24h in the future. Instead of ignoring an issue permanently just to make a build pass, one can postpone it when in rush, but make it show up as a CI faiure on the next working day. +- **remove** runs `npm rm` on the top level dependency containing the issue. It's a convenience option for the user to remove an old package which they no longer intend to use. ++- **investigate** when fix is not available, investigate option shows instead. It goes up through the dependencies chain and finds the one that needs their package.json updated with new version specification to enable a fix. +The result can be a call to action to create a PR (patch to package.json could be automatically generated)++**skip** and **abort** options should also be provided.++## Rationale and Alternatives++**Ignoring is necessary but must be under control at all times**+- `nsp check` used to support ignoring a particular issue in all dependencies, but that's not enough to be in control and remain secure. It wasn't uncommon for projects to ignore an advisory id because it was coming up as an issue in code that didn't run in production, thus risking it getting into the production code when updating another dependency to a version with the same issue.+- ignoring just dev dependencies is not enough. Sometimes the developer knows a vulnerability can be ignored because a package with a DOS is used in tooling for the project (not a dev dependency but eg. a migration script), not production code. To be really secure, ignoring must be explicit. +- Editing a file to specify what to ignore will not suffice any more at that level of detail, so automation is necessary.++**Why audit-resolve.json?**+Resolutions must be recorded in a file and committed to git(or alternative) for edit history and full audit on who decided what.+Resolution format must be readable for a JavaScript developer.++- `package-lock.json` is not a good option for storing resolutions because even if we overlook the fact that it'd be adding another purpose to a single-purpose file, the community at large is still used to removing and regenerating it often. +- `package.json` is not a good option, because it is already overloaded for so many functionalities. The output of resolutions could be lengthy and clutter the file. User will need the resolution information much less often than they look in the package.json file. ALso, resolution file is not meant to be edited by hand.+- `.npmrc` is not a good option because it doesn't live in the repository and being a dotfile is easy to miss, so a developer could overlook it affecting the audit. Also using it for the purpose of storing resolutions to project specific issues seems counter-intuitive.++A separate file referred to as `audit-resolve.json` has the benefit of being single purpose, easy to track and audit, easy to version and migrate between versions of `npm` and comfortable for the users to review in git history and pull requests.++**postpone, remove, investigate**+Other options are helpers for more elaborate actions a developer would take when confronted with an issue they can't or don't want to fix. ++Why is postpone useful at all? It's designed to build a secure development culture where one didn't yet form. Without it, a developer under time pressure would mark an issue as ignored with intention to un-mark it later. +While shipping with a known vulnerability is a bad practice, NPM's mission with the community should be to empower people to build more secure products and trust their skill and understanding of their project's particular needs. We should also aspire to help teams introduce more secure workflows effortlessly, so letting a build pass without risking compromising security long-term is a win. ++Remove is only useful as a convenience. Imagine a developer introducing `npm audit` and having to go through tens of issues. If they notice one of the first issues is caused by a dependency they no longer use, instead of remembering to clean it up later, they can choose this option.++Investigate option is there to aid the user and direct them towards fixing the issue upstream.+This RFC doesn't cover potential future usecases where NPM could do things ranging from linking to resources on mitigation to generating local fixes or providing a marketplace of companies offering services fixing the issue for customers (business potential for NPM).++### Alternatives++Currently the only alternative is to manage the issues manually and keep track of the resolutions using conventions created by a team individually. Ignoring dev dependencies and certain level of severity will be provided for `npm audit` so it lowers the barrier of entry to using it in a CI system. ++Paid alternatives for managing security of a node.js project are available, including Snyk, with focus on providing patches to their customers.++## Implementation++reference implementation https://github.com/npm/cli/pull/10++prototype of a working tool (in production use) https://www.npmjs.com/package/npm-audit-resolver++The implementation is, and should remain, runnable standalone as a separate package with minor wrapping code - useful for testing new features without bundling unfinished work with npm cli versions and therefore node.js

right, twitter sucks these days... it used to notify people whenever someone starts following them

but no worries, I’ll shoot you an email them 😊

naugtur

comment created time in 4 days

Pull request review commentnpm/rfcs

npm audit resolve

+# Interactive audit resolver++## Summary++This proposal is for adding means for a human to resolve issues from `npm audit` and interactively make decisions about each issue. Available as `npm audit resolve` command.++Features:+- Remember the resolutions and allow them to affect `npm audit` behavior.+- Decision options include 'ignore', 'remind later', 'fix', 'remove'.+- Allow tracking who resolved an issue and when using git history.+++## Motivation++At times, running `npm audit fix` won't fix all audit issues. Fixes might not be available or the user might not want to apply some of them, eg. major version updates or build/test dependencies.++It should be possible to make `npm audit` a step in a CI pipeline to go red every time a new vulnerability affects the project. Managing security of dependencies should be quick to update, effective, easy to audit over time and secure in itself.++For that, the user needs a new tool which makes addressing issues one by one convenient even across a whole ecosystem of projects.++## Detailed Explanation++`npm audit resolve` runs audit and iterates over all actions from the output with a prompt for a decision on each. +If fix is available, it's offered as one of the options to proceed. Other options include: ignore, remind later and delete.++All decisions are stored in `audit-resolve.json` file as key-value, where key is `${advisory id}|${dependency path}` and value is:++```js+{+  decision: "fix|ignore|postpone",+  madeAt: <timestamp of when the decision was made>+}+```++`npm audit` reads `audit-resolve.json` and respects the resolution (ignores ignored issues, ignores issues postponed to a date in the future)++### resolutions+- **fix** runs the fix proposed in audit action and marks the issue as fixed in `audit-resolve.json`. On each subsequent run of `npm audit resolve` if the issue comes up again, the user is also warned that the problem was supposed to be fixed already.+- **ignore** marks the issue as ignored and `npm audit` will no longer fail because of it (but should display a single line warning about the issue being ignored). If a new vulnerability is found in the same dependency, it does not get ignored. If another dependency is installed with the same vulnerability advisory id it is not ignored. If the same package is installed as a dependency to another dependency (different path) it is not ignored.+- **postpone** marks the issue as postponed to a timestamp 24h in the future. Instead of ignoring an issue permanently just to make a build pass, one can postpone it when in rush, but make it show up as a CI faiure on the next working day. +- **remove** runs `npm rm` on the top level dependency containing the issue. It's a convenience option for the user to remove an old package which they no longer intend to use. ++- **investigate** when fix is not available, investigate option shows instead. It goes up through the dependencies chain and finds the one that needs their package.json updated with new version specification to enable a fix. +The result can be a call to action to create a PR (patch to package.json could be automatically generated)++**skip** and **abort** options should also be provided.++## Rationale and Alternatives++**Ignoring is necessary but must be under control at all times**+- `nsp check` used to support ignoring a particular issue in all dependencies, but that's not enough to be in control and remain secure. It wasn't uncommon for projects to ignore an advisory id because it was coming up as an issue in code that didn't run in production, thus risking it getting into the production code when updating another dependency to a version with the same issue.+- ignoring just dev dependencies is not enough. Sometimes the developer knows a vulnerability can be ignored because a package with a DOS is used in tooling for the project (not a dev dependency but eg. a migration script), not production code. To be really secure, ignoring must be explicit. +- Editing a file to specify what to ignore will not suffice any more at that level of detail, so automation is necessary.++**Why audit-resolve.json?**+Resolutions must be recorded in a file and committed to git(or alternative) for edit history and full audit on who decided what.+Resolution format must be readable for a JavaScript developer.++- `package-lock.json` is not a good option for storing resolutions because even if we overlook the fact that it'd be adding another purpose to a single-purpose file, the community at large is still used to removing and regenerating it often. +- `package.json` is not a good option, because it is already overloaded for so many functionalities. The output of resolutions could be lengthy and clutter the file. User will need the resolution information much less often than they look in the package.json file. ALso, resolution file is not meant to be edited by hand.+- `.npmrc` is not a good option because it doesn't live in the repository and being a dotfile is easy to miss, so a developer could overlook it affecting the audit. Also using it for the purpose of storing resolutions to project specific issues seems counter-intuitive.++A separate file referred to as `audit-resolve.json` has the benefit of being single purpose, easy to track and audit, easy to version and migrate between versions of `npm` and comfortable for the users to review in git history and pull requests.++**postpone, remove, investigate**+Other options are helpers for more elaborate actions a developer would take when confronted with an issue they can't or don't want to fix. ++Why is postpone useful at all? It's designed to build a secure development culture where one didn't yet form. Without it, a developer under time pressure would mark an issue as ignored with intention to un-mark it later. +While shipping with a known vulnerability is a bad practice, NPM's mission with the community should be to empower people to build more secure products and trust their skill and understanding of their project's particular needs. We should also aspire to help teams introduce more secure workflows effortlessly, so letting a build pass without risking compromising security long-term is a win. ++Remove is only useful as a convenience. Imagine a developer introducing `npm audit` and having to go through tens of issues. If they notice one of the first issues is caused by a dependency they no longer use, instead of remembering to clean it up later, they can choose this option.++Investigate option is there to aid the user and direct them towards fixing the issue upstream.+This RFC doesn't cover potential future usecases where NPM could do things ranging from linking to resources on mitigation to generating local fixes or providing a marketplace of companies offering services fixing the issue for customers (business potential for NPM).++### Alternatives++Currently the only alternative is to manage the issues manually and keep track of the resolutions using conventions created by a team individually. Ignoring dev dependencies and certain level of severity will be provided for `npm audit` so it lowers the barrier of entry to using it in a CI system. ++Paid alternatives for managing security of a node.js project are available, including Snyk, with focus on providing patches to their customers.++## Implementation++reference implementation https://github.com/npm/cli/pull/10++prototype of a working tool (in production use) https://www.npmjs.com/package/npm-audit-resolver++The implementation is, and should remain, runnable standalone as a separate package with minor wrapping code - useful for testing new features without bundling unfinished work with npm cli versions and therefore node.js

for sure it would be nice to catch up, I tried reaching out on twitter but let me know if there's a better place to start a conversation 😊

naugtur

comment created time in 4 days

Pull request review commentnpm/rfcs

npm audit resolve

+# Interactive audit resolver++## Summary++This proposal is for adding means for a human to resolve issues from `npm audit` and interactively make decisions about each issue. Available as `npm audit resolve` command.++Features:+- Remember the resolutions and allow them to affect `npm audit` behavior.+- Decision options include 'ignore', 'remind later', 'fix', 'remove'.+- Allow tracking who resolved an issue and when using git history.+++## Motivation++At times, running `npm audit fix` won't fix all audit issues. Fixes might not be available or the user might not want to apply some of them, eg. major version updates or build/test dependencies.++It should be possible to make `npm audit` a step in a CI pipeline to go red every time a new vulnerability affects the project. Managing security of dependencies should be quick to update, effective, easy to audit over time and secure in itself.++For that, the user needs a new tool which makes addressing issues one by one convenient even across a whole ecosystem of projects.++## Detailed Explanation++`npm audit resolve` runs audit and iterates over all actions from the output with a prompt for a decision on each. +If fix is available, it's offered as one of the options to proceed. Other options include: ignore, remind later and delete.++All decisions are stored in `audit-resolve.json` file as key-value, where key is `${advisory id}|${dependency path}` and value is:

ah 😄 sorry about that, I meant https://github.com/npm/arborist

naugtur

comment created time in 4 days

issue closednpm/rfcs

OpenRFC Meeting - Wednesday, May 20, 2020, 2:00 PM EST

Why?

In our ongoing efforts to better listen to & collaborate with the community, we've started an Open RFC deep dive call that helps to move a specific conversation and/or initiative forward.

When?

Wednesday, May 20, 2020, 2:00 PM EST

Cadence: This meeting is scheduled to take place bi-weekly alternating with our regular Open RFC calls. Previous meeting agendas and notes can be found here

Add to your Calendar: You follow this & find other npm events by using our public events calendar

What?

All discussions surrounding RFCs are covered by the npm Code of Conduct. Please keep conversations constructive, civil & be mindful of when others are speaking. As is tradition, "raise your hand" when requesting to comment on a topic or request to comment asynchronously within the chat. The npm team may, at its own discretion, moderate, mute &/or remove a person from an Open RFC call for any reason.

Invited Attendees

  • Anyone interested in the idea of staging/stage publishes (please review the PRs beforehand)

Agenda

  1. Housekeeping
    1. Introduction(s)
    2. Code of Conduct Acknowledgement
    3. Outline Intentions & Desired Outcomes
    4. Announcements
  2. Topic(s):
  3. PR: #135 Clarify/Outline the RFC Withdrawal Process & Amendment
  4. PR: #133 RFC: Remove --depth from npm outdated
  5. PR: #135 RFC: Add npm-app-id HTTP header
  6. PR: #144 RFC: npm diff
  7. PR: #146 RFC: Notification system for cli updates
  8. PR: #126 RFC: Adding types information to the Package JSON in the registry
  9. PR: #18 RFC: audit resolve
  10. PR: #121 Added proposal for package version link#[version] syntax
  11. PR: #117 RFC: npm workspaces - Running Commands

How?

Join Zoom Meeting https://npm.zoom.us/j/914742332

Meeting ID: 914 742 332

One tap mobile +16465588656,,914742332# US (New York) +16699006833,,914742332# US (San Jose)

Dial by your location +1 646 558 8656 US (New York) +1 669 900 6833 US (San Jose) Meeting ID: 914 742 332 Find your local number: https://npm.zoom.us/u/abR8OFljr8

closed time in 5 days

darcyclarke

issue commentnpm/rfcs

OpenRFC Meeting - Wednesday, May 20, 2020, 2:00 PM EST

Video record: https://youtu.be/W6XbJ5e3xrA

darcyclarke

comment created time in 5 days

pull request commentnpm/rfcs

RFC: Notification system for cli updates

Feedback from OpenRFC meeting:

  • state of the registry engineering resources makes it difficult to commit to adding new features to the registry right now
ruyadorno

comment created time in 5 days

issue closednpm/cli

[FEATURE] Add audit resolve/fix management

What / Why

<!-- Describe the request in detail --> Would be great to have an interactive update command for npm audit fix

Where

<!-- Examples

  • npm enterprise
  • npm public registry
  • npm/<repository> -->
  • npm audit fix

How

Current Behavior

<!-- Describe how it currently works -->

  • Not interactive

Expected Behavior

<!-- Describe how it should work -->

  • Cool interactive menu

References

<!-- Examples

  • Related to #0
  • Depends on #0
  • Blocked by #0 -->
  • https://github.com/npm/cli/pull/168

closed time in 5 days

mikemimik

issue commentnpm/cli

[FEATURE] Add audit resolve/fix management

closing this in favor of continuing the conversation over at https://github.com/npm/rfcs/pull/18

mikemimik

comment created time in 5 days

Pull request review commentnpm/rfcs

Interactive audit resolver

+# Interactive audit resolver++## Summary++This proposal is for adding means for a human to resolve issues from `npm audit` and interactively make decisions about each issue. Available as `npm audit resolve` command.++Features:+- Remember the resolutions and allow them to affect `npm audit` behavior.+- Decision options include 'ignore', 'remind later', 'fix', 'remove'.+- Allow tracking who resolved an issue and when using git history.+++## Motivation++At times, running `npm audit fix` won't fix all audit issues. Fixes might not be available or the user might not want to apply some of them, eg. major version updates or build/test dependencies.++It should be possible to make `npm audit` a step in a CI pipeline to go red every time a new vulnerability affects the project. Managing security of dependencies should be quick to update, effective, easy to audit over time and secure in itself.++For that, the user needs a new tool which makes addressing issues one by one convenient even across a whole ecosystem of projects.++## Detailed Explanation++`npm audit resolve` runs audit and iterates over all actions from the output with a prompt for a decision on each. +If fix is available, it's offered as one of the options to proceed. Other options include: ignore, remind later and delete.++All decisions are stored in `audit-resolve.json` file as key-value, where key is `${advisory id}|${dependency path}` and value is:

@isaacs I'm under the impression that the ${dependencyPath} bit here is very non-arborist and not necessary overall in the context of an audit triage system, would like to hear your thoughts on it

naugtur

comment created time in 5 days

Pull request review commentnpm/rfcs

Interactive audit resolver

+# Interactive audit resolver++## Summary++This proposal is for adding means for a human to resolve issues from `npm audit` and interactively make decisions about each issue. Available as `npm audit resolve` command.++Features:+- Remember the resolutions and allow them to affect `npm audit` behavior.+- Decision options include 'ignore', 'remind later', 'fix', 'remove'.+- Allow tracking who resolved an issue and when using git history.+++## Motivation++At times, running `npm audit fix` won't fix all audit issues. Fixes might not be available or the user might not want to apply some of them, eg. major version updates or build/test dependencies.++It should be possible to make `npm audit` a step in a CI pipeline to go red every time a new vulnerability affects the project. Managing security of dependencies should be quick to update, effective, easy to audit over time and secure in itself.++For that, the user needs a new tool which makes addressing issues one by one convenient even across a whole ecosystem of projects.++## Detailed Explanation++`npm audit resolve` runs audit and iterates over all actions from the output with a prompt for a decision on each. +If fix is available, it's offered as one of the options to proceed. Other options include: ignore, remind later and delete.++All decisions are stored in `audit-resolve.json` file as key-value, where key is `${advisory id}|${dependency path}` and value is:++```js+{+  decision: "fix|ignore|postpone",+  madeAt: <timestamp of when the decision was made>+}+```++`npm audit` reads `audit-resolve.json` and respects the resolution (ignores ignored issues, ignores issues postponed to a date in the future)++### resolutions+- **fix** runs the fix proposed in audit action and marks the issue as fixed in `audit-resolve.json`. On each subsequent run of `npm audit resolve` if the issue comes up again, the user is also warned that the problem was supposed to be fixed already.+- **ignore** marks the issue as ignored and `npm audit` will no longer fail because of it (but should display a single line warning about the issue being ignored). If a new vulnerability is found in the same dependency, it does not get ignored. If another dependency is installed with the same vulnerability advisory id it is not ignored. If the same package is installed as a dependency to another dependency (different path) it is not ignored.+- **postpone** marks the issue as postponed to a timestamp 24h in the future. Instead of ignoring an issue permanently just to make a build pass, one can postpone it when in rush, but make it show up as a CI faiure on the next working day. +- **remove** runs `npm rm` on the top level dependency containing the issue. It's a convenience option for the user to remove an old package which they no longer intend to use. ++- **investigate** when fix is not available, investigate option shows instead. It goes up through the dependencies chain and finds the one that needs their package.json updated with new version specification to enable a fix. +The result can be a call to action to create a PR (patch to package.json could be automatically generated)++**skip** and **abort** options should also be provided.++## Rationale and Alternatives++**Ignoring is necessary but must be under control at all times**+- `nsp check` used to support ignoring a particular issue in all dependencies, but that's not enough to be in control and remain secure. It wasn't uncommon for projects to ignore an advisory id because it was coming up as an issue in code that didn't run in production, thus risking it getting into the production code when updating another dependency to a version with the same issue.+- ignoring just dev dependencies is not enough. Sometimes the developer knows a vulnerability can be ignored because a package with a DOS is used in tooling for the project (not a dev dependency but eg. a migration script), not production code. To be really secure, ignoring must be explicit. +- Editing a file to specify what to ignore will not suffice any more at that level of detail, so automation is necessary.++**Why audit-resolve.json?**+Resolutions must be recorded in a file and committed to git(or alternative) for edit history and full audit on who decided what.+Resolution format must be readable for a JavaScript developer.++- `package-lock.json` is not a good option for storing resolutions because even if we overlook the fact that it'd be adding another purpose to a single-purpose file, the community at large is still used to removing and regenerating it often. +- `package.json` is not a good option, because it is already overloaded for so many functionalities. The output of resolutions could be lengthy and clutter the file. User will need the resolution information much less often than they look in the package.json file. ALso, resolution file is not meant to be edited by hand.+- `.npmrc` is not a good option because it doesn't live in the repository and being a dotfile is easy to miss, so a developer could overlook it affecting the audit. Also using it for the purpose of storing resolutions to project specific issues seems counter-intuitive.++A separate file referred to as `audit-resolve.json` has the benefit of being single purpose, easy to track and audit, easy to version and migrate between versions of `npm` and comfortable for the users to review in git history and pull requests.++**postpone, remove, investigate**+Other options are helpers for more elaborate actions a developer would take when confronted with an issue they can't or don't want to fix. ++Why is postpone useful at all? It's designed to build a secure development culture where one didn't yet form. Without it, a developer under time pressure would mark an issue as ignored with intention to un-mark it later. +While shipping with a known vulnerability is a bad practice, NPM's mission with the community should be to empower people to build more secure products and trust their skill and understanding of their project's particular needs. We should also aspire to help teams introduce more secure workflows effortlessly, so letting a build pass without risking compromising security long-term is a win. ++Remove is only useful as a convenience. Imagine a developer introducing `npm audit` and having to go through tens of issues. If they notice one of the first issues is caused by a dependency they no longer use, instead of remembering to clean it up later, they can choose this option.++Investigate option is there to aid the user and direct them towards fixing the issue upstream.+This RFC doesn't cover potential future usecases where NPM could do things ranging from linking to resources on mitigation to generating local fixes or providing a marketplace of companies offering services fixing the issue for customers (business potential for NPM).++### Alternatives++Currently the only alternative is to manage the issues manually and keep track of the resolutions using conventions created by a team individually. Ignoring dev dependencies and certain level of severity will be provided for `npm audit` so it lowers the barrier of entry to using it in a CI system. ++Paid alternatives for managing security of a node.js project are available, including Snyk, with focus on providing patches to their customers.++## Implementation++reference implementation https://github.com/npm/cli/pull/10++prototype of a working tool (in production use) https://www.npmjs.com/package/npm-audit-resolver++The implementation is, and should remain, runnable standalone as a separate package with minor wrapping code - useful for testing new features without bundling unfinished work with npm cli versions and therefore node.js

It would be nice to describe a bit more the implementation over here, an example of the cli UX would be very welcomed, maybe just copy or start from the example I floated over https://github.com/npm/cli/issues/525#issuecomment-573928594

$ npm audit resolve list
1325 [high]     handlebars: Prototype Pollution
1324 [high]     handlebars: Arbitrary Code Execution
788  [moderate] js-yaml: Denial of Service

$ npm audit resolve get 788
Status: Pending
Level: Moderate
Type: Denial of Service
Package name: js-yaml
Dependency of: tap [dev]
Path: tap > tap-parser > js-yaml
More info: https://npmjs.com/advisories/788

$ npm audit resolve set 788 --status=Read

$ npm audit resolve list
1325 [high]     handlebars: Prototype Pollution
1324 [high]     handlebars: Arbitrary Code Execution

$ npm audit resolve get 788
Status: Read
Level: Moderate
Type: Denial of Service
Package name: js-yaml
Dependency of: tap [dev]
Path: tap > tap-parser > js-yaml
More info: https://npmjs.com/advisories/788
naugtur

comment created time in 5 days

pull request commentnpm/rfcs

Interactive audit resolver

Hi @naugtur picking up from where the conversation ended last time: https://github.com/npm/cli/issues/525#issuecomment-577907157

We would love to start working on npm audit resolve now that v7 is taking shape 😊

That said, do you want to update this RFC to reflect the changes we mentioned in that issue? (specially the part about not making it an interactive command anymore) It's up to you to decide if you want to bring this RFC across the finish line - I realize it's been ages since you first opened it and totally understand if you're not interested in following up anymore 😁 We def appreciate all the work that you've put into this RFC and npm-audit-resolver ❤️

naugtur

comment created time in 5 days

pull request commentnpm/rfcs

RFC: Add npm diff

btw we actually have a working prototype over at https://github.com/npm/cli/pull/1319

ruyadorno

comment created time in 5 days

Pull request review commentnpm/rfcs

RFC: Add npm diff

+# npm diff++## Summary++Add a new command that enables diff workflows (similar to `git diff`) for packages published in the registry.++## Motivation++- Complements `npm audit` and `npm outdated` workflows by providing insight on what changed across different package versions+- Enables package authors to diff packlist-tracked-only file changes prior to publishing a new version of a package++## Detailed Explanation++Introduce a new `npm diff` command that will fetch tarball contents for two different versions of a module and print that output in an usable format to users.++### npm diff `<spec>`++Using a single `<spec>` allows users to retrieve diff output between an existing valid version of a package with the same **name** found in the actual dependency tree and the exact `<spec>` match from the registry.++<img alt="Demo showing npm diff pkg in a repo with an actual tree installed" src="https://ruyadorno.github.io/svg-demos/npm-diff/npm-diff-yargs.svg" />++### npm diff `<spec-a>` `<spec-b>`++Fetches tarball contents of two versions of a package, represented by `<spec-a>` and `<spec-b>` and prints diff output.++<img alt="Demo showing npm diff pkg in a repo with an actual tree installed" src="https://ruyadorno.github.io/svg-demos/npm-diff/npm-diff-simple-output.svg" />++### npm diff --changelog

oh yeah, a proper changelog section in the website UI would be neat, specially one that does fallback to looking up GitHub releases 🤩

now back to your original point, I think it makes a lot of sense to have a file-filter argument, as I commented during the call it would enable us to do neat things in companion of the --name-only flag, workflows such as: npm diff --name-only | grep index | xargs git diff or have an interactive workflow that allows you to select from the list of files: npm diff --name-only | npx ipt | xargs git diff

ruyadorno

comment created time in 5 days

startedobetomuniz/tatooine

started time in 5 days

pull request commentnpm/rfcs

RFC: overrides

following up from the discussion at: https://github.com/npm/rfcs/discussions/78#discussioncomment-16512

@isaacs do you think in its current state this RFC enables that usecase?

isaacs

comment created time in 5 days

Pull request review commentnpm/rfcs

RFC: Notification system for cli updates

+# Notification system for cli updates++## Summary++A new notification system to warn users about new versions of the **npm cli**.++## Motivation++- Remove an extra http request from the cli

my guess is that when this was brought up it was with regards to commands that should not necessarily hit the registry, such as npm ls but i do agree with your point, it might be silly and not worth having this listed in the RFC after all

ruyadorno

comment created time in 5 days

PR opened npm/rfcs

RFC: Notification system for cli updates
+31 -0

0 comment

1 changed file

pr created time in 6 days

create barnchruyadorno/rfcs

branch : new-cli-update-notification-system

created branch time in 6 days

PR opened npm/rfcs

RFC: Add npm diff
+60 -0

0 comment

1 changed file

pr created time in 6 days

push eventruyadorno/rfcs

Ruy Adorno

commit sha 0ba158a532e22f5a3377f515e4e6301b8bd4730b

RFC: Add npm diff

view details

push time in 6 days

create barnchruyadorno/rfcs

branch : npm-diff

created branch time in 6 days

push eventnpm/rfcs

Evan Summers

commit sha dad515261df96b30fa84f23e966588db7349baf3

Minor typo in `accepted/0026-workspaces.md` (#140)

view details

push time in 6 days

PR merged npm/rfcs

Minor typo in `accepted/0026-workspaces.md`

What / Why

<!-- Describe the request in detail -->

n/a

References

<!-- Examples

  • Related to #0
  • Depends on #0
  • Blocked by #0
  • Closes #0 -->
  • n/a
+1 -1

0 comment

1 changed file

Strongbyte-ES

pr closed time in 6 days

PR closed npm/rfcs

nem/rfcs request

What / Why

<!-- Describe the request in detail -->

n/a

References

<!-- Examples

  • Related to #0
  • Depends on #0
  • Blocked by #0
  • Closes #0 -->
  • n/a
+105 -3

1 comment

5 changed files

mtdev2

pr closed time in 6 days

pull request commentnpm/rfcs

nem/rfcs request

hi @mtdev2 thanks for opening a PR but unfortunately this repo doesn't really need issue templates or a GitHub action 😊 This repo exists so that the community can participate more actively in the development of the npm cli and usually the discussion happens around templated PRs that might propose a new feature/change in the cli or more recently we adopted GitHub discussions so that other less-structured conversation can happen without necessarily relying on GitHub issues.

mtdev2

comment created time in 6 days

pull request commentnpm/cli

chore: arborist fund cmd refactor

I had a quick chat with @isaacs related to this and I'd actually like to pluck out lib/utils/funding.js into a lib of its own, like @npmcli/funding or something

ruyadorno

comment created time in 6 days

push eventnpm/cli

Ruy Adorno

commit sha 07202278fea3554eea19ebcb47eb380639e7fc0a

added color support

view details

push time in 7 days

push eventruyadorno/svg-demos

Ruy Adorno

commit sha 9e422cbdd1152c13f308bf1c314649094af1d25d

update npm-diff demos

view details

push time in 7 days

created tagmillermedeiros/disparity

tagv3.1.0

colorized string diff (char or unified) ideal for text/code that spans through multiple lines

created time in 7 days

push eventmillermedeiros/disparity

Ruy Adorno

commit sha 574e6ee6ff5bb2a1c334e456455c48f5832523a6

add disparity.d.ts to list of files

view details

Ruy Adorno

commit sha cffa254b9a133921f3b396459c7e02b4c9425933

bumped deps

view details

Ruy Adorno

commit sha b4fd2d6a8d53eb657b2f5af8a90ad4780df35408

3.1.0

view details

push time in 7 days

issue commentmillermedeiros/disparity

Support passing additional options instead of requiring export mutation

yeah def agree, it would make for a much better api 👍

one thing though is that given how long the library has been around I think it would make a lot of sense to preserve the old API and have the options live alongside with the exports (I'd really prefer to avoid forcing breaking changes downstream) - so have it in a way that the options take precedence but defaults to using the old exports definitions if undefined

What do you think? 😊

G-Rath

comment created time in 7 days

push eventmillermedeiros/disparity

Gareth Jones

commit sha 93bff88c1d220aeb99a0609e1993b2eb1d7febcf

Add type definitions

view details

Ruy Adorno

commit sha 72eaa84d8a7365588824d1a3bfd7479e5b949a25

Merge pull request #8 from G-Rath/add-type-definitions Add type definitions

view details

push time in 7 days

PR merged millermedeiros/disparity

Reviewers
Add type definitions

Thanks a ton for this library - it was exactly what I was looking for!

I wrote type definitions so I could use it in TypeScript - feel free to ask me if you've got any questions :)

+112 -0

1 comment

3 changed files

G-Rath

pr closed time in 7 days

pull request commentmillermedeiros/disparity

Add type definitions

LGTM 👍

G-Rath

comment created time in 7 days

pull request commentnpm/cli

npm diff

Before landing this, it'd be great to discuss it on an RFC call to make sure everyone's use cases are considered.

for sure! 😄

ruyadorno

comment created time in 7 days

push eventruyadorno/svg-demos

Ruy Adorno

commit sha ed95d1e5cd6b85316ba8bef82b6231539a8c6091

add npm-diff no args

view details

push time in 7 days

push eventnpm/cli

Ruy Adorno

commit sha 41d9056e92eeb2242fccf811b2779e2e93149184

added no args `npm diff`

view details

push time in 7 days

pull request commentnpm/cli

npm diff

Prior art: https://npmjs.com/lockfile-diff

A more similar userland solution I found was this script: https://github.com/juliangruber/npm-diff

ruyadorno

comment created time in 8 days

push eventnpm/cli

Ruy Adorno

commit sha b4a600b4effd3f072581a06251a82d8082ed554e

fixes

view details

push time in 8 days

CommitCommentEvent

PR opened npm/cli

npm diff

The registry diff command

Introduce a new npm diff command that can offer a new workflow for maintainers, going beyond and complementing the experience from npm outdated and npm audit.

Usecases

npm outdated + npm diff <pkg>

A very common workflow is using npm outdated to figure out what dependencies need update and then manually reviewing what changed in between the current version you have in your project and whatever you can update to. That workflow involves multiple steps, some of them being extra mental hurdle (such as keeping track of the semver versions change and their meaning) some other very manual such as jumping around to repos, scanning through changelogs, veryfing semver contract is respected, etc.

Given the very long tail of packages published in the registry, a vast majority of packages sit somewhere below the 100LOC or a single function or whatever other measurement unit to define the pattern of very specialized and small packages adopted by the JavaScript ecosystem (speaking from personal experience here but maybe we can get some numbers to validate this assumption in case this is a contentious statement) - thus being perfect candidates to a simple review of the diff patches between versions.

Demo time:

<img alt="Demo showing npm diff <pkg> in a repo with an actual tree installed" src="https://ruyadorno.github.io/svg-demos/npm-diff/diff-pkg.svg" />

npm audit + npm diff <spec-a> <spec-b> + npm install <spec-b>

If you're not currently in a project that has an actual tree installed, you can still compare two versions by using two arguments defining two different specs to test for:

<img alt="Demo showing npm diff <pkg> in a repo with an actual tree installed" src="https://ruyadorno.github.io/svg-demos/npm-diff/npm-diff-minimist.svg" />

npm diff <pkg> --changelog

Filter to only show CHANGELOG changes, makes the command more useful for larger packages such as frameworks, etc.

<img alt="Demo showing npm diff <pkg> in a repo with an actual tree installed" src="https://ruyadorno.github.io/svg-demos/npm-diff/npm-diff-changelog.svg" />

npm diff across forks

Comparing against different specs but actually pointing at a different package which is a fork of an existing one (just to show some other different usages)

<img alt="Demo showing npm diff <pkg> in a repo with an actual tree installed" src="https://ruyadorno.github.io/svg-demos/npm-diff/npm-diff-fork.svg" />

What's in here

  • git-patch-compatible output so that users can plug in any existing tools they already have as part of their workflow and enables IDE/tools to also easily integrate to it
  • npm diff <spec> comparing a current installed package to a spec defined by the user
  • npm diff <spec-a> <spec-b> compares two diff published versions of a package
  • npm diff <specs...> --changelog output only diff of a changelog file (maybe we can also integrate to GH APIs to fetch release data for packages pointing to GH repos?)

TODO

  • tests
  • docs
  • support to using npm diff with no params, which I imagine being useful for developers in order to diff the delta between current files (respecting npm-packlist) and the latest published version (or customizable dist-tag)
+444 -0

0 comment

13 changed files

pr created time in 8 days

push eventruyadorno/svg-demos

Ruy Adorno

commit sha f3bf23942bc2fb648a3ad9c30090b0cc5d23921c

added fork example

view details

push time in 8 days

push eventruyadorno/svg-demos

Ruy Adorno

commit sha 537951060bee3379806cd2ab90b8cfa4287d9222

npm diff demos

view details

push time in 8 days

push eventnpm/cli

Ruy Adorno

commit sha e3eca95472f26c6264db40586dc809562dff26b7

add mimer dep

view details

push time in 8 days

push eventnpm/cli

Ruy Adorno

commit sha 31cb5456ad6b1347b888467c4a01ef9b052b8bc1

feat: add npm diff

view details

push time in 8 days

create barnchnpm/cli

branch : ruyadorno/npm-diff

created branch time in 9 days

issue commentnodejs/tooling

stdin.read interface

now that TLA landed on master, combined with the async/await stream support we have a more reasonable interface for consuming process.stdin in such eval oneliners:

-cat README.md | node -e "inp=''; process.stdin.on('data',c=>inp+=c).on('end',()=>process.stdout.write(inp.replace(/[a-z]/g, 'x')))"
+cat README.md | node -e "for await (const c of process.stdin) process.stdout.write(c.toString().replace(/[a-z]/g, 'x'))"

Note: Requires --experimental-top-level-await and --input-type=module flags in current master

ruyadorno

comment created time in 10 days

PR opened npm/cli

chore: arborist fund cmd refactor

Changes:

  • npm fund cmd:
    • no longer depends on lib/install modules
    • now it uses arborist tree and inventory to retrieve funding data
    • refactor to use same exports patterns to new commands
    • changed human output to reinstate representation of nested deps
  • install:
    • no longer breaks on missing audit report
    • refactored reify-output to use utils/funding module
    • added tests for utils.reify-output fund summary
  • lib/utils/funding.js:
    • updates in order to traverse the new arborist ideal tree

Note:

  • There are a couple of TODO items left but I feel confident that with this refactor the fund cmd is at least in a pretty good usable state for v7, the missing items are:
    • Some of the tests cases for the install mention were disabled since they're not getting the same expected output as before, it still needs some more digging into arborist details but it seems that arborist is not being capable of reaching to file:../<path> in dependency declarations
    • Temporarily removed the part in npm fund <pkg> that fetches packument metadata in order to provide funding info for any published package that might not be part of the actual tree, I would like to know better if we plan to keep using ./lib/fetch-package-metadata or shift to a leaner pacote.manifest call, that can be tackled in a follow up PR though

/cc @isaacs

+1060 -912

0 comment

11 changed files

pr created time in 10 days

push eventnpm/cli

Ruy Adorno

commit sha c67ee3be67bd37a14a74733447657d9df3bd10ba

chore: arborist fund cmd refactor - npm fund cmd: - no longer depends on `lib/install` modules - now it uses arborist tree and inventory to retrieve funding data - refactor to use same exports patterns to new commands - changed human output to reinstate representation of nested deps - install: - no longer breaks on missing audit report - refactored `reify-output` to use `utils/funding` module - added tests for utils.reify-output fund summary - lib/utils/funding.js: - updates in order to traverse the new arborist ideal tree

view details

push time in 10 days

PR opened npm/arborist

fix: avoid throwing type erros on inventory.add

Trying to load mock malformed testing data from the cli resulted in an unexpected TypeError. The issue can be reproduced by having a falsy funding property in a package.json, as seen here: https://github.com/npm/cli/blob/abdf52879fcf0e0f534ad977931f6935f5d1dce3/test/tap/fund.js#L81

This commit fixes the problem by avoiding trying to retrieve the typeand url properties when having a null object reference.

While I considered the alternative of throwing a more descriptive error instead of having TypeError: Cannot read property 'url' of null - I think in this case not blowing up is a much more convenient and reasonable behavior.

+20 -1

0 comment

2 changed files

pr created time in 11 days

create barnchruyadorno/arborist

branch : avoid-type-error-on-falsy-inventory-add

created branch time in 11 days

push eventruyadorno/grunt-menu

mariomui

commit sha 54fb8252f141be687f4159e06246ff1f3f3a397e

Update readme with a better explanation of how to explicit state descriptions in the menu listing.

view details

Ruy Adorno

commit sha da7b5dcd06329a8b475b092c4059eeecdb0fdf8a

Merge pull request #3 from mariomui-viscira/develop Update readme with a better explanation of how to explicit state descriptions in the menu listing.

view details

push time in 11 days

issue openedopenjs-foundation/summit

Session Proposal:

Proposal

<!-- Thank you! You are submitting a topic for the next Collaborator's Summit, Austin (TX) 2020!

Please include as much detail as you are able to at this moment. Don't worry, it doesn't have to be complete.

Please feel free to link to any other issue, PR, or resource that could be relevant. -->

Topic of the session npm open rfc meeting

<!-- Example: "Session space for jQuery Core contributors" -->

Type of the session

<!-- Replace the space between the brackets with an x, like [x], to create a checked box. -->

  • [x] Collaborate
  • [ ] Workshop
  • [ ] Talk

Timezone of facilitator

  • Eastern Time Zone, North-America

<!-- As the event is taking place online the organiser need to know your availability to schedule the track accordingly. For more information, see https://everytimezone.com/ -->

Estimated duration of the session 1 hour

Follow-up / Set-up sessions (if any) N/A

Level

<!-- This is the expected level of familiarity with the subject of the session.

Example: If the subject of the session is Node.js, and participants cannot contribute without minimum Intermediate familiarity, the x should go in Intermediate and Advanced.

Note that your choice of Level will signal expectations to your potential participants. -->

  • [x] Beginner
  • [x] Intermediate
  • [x] Advanced

Pre-requisite knowledge Anyone interested in the future of npm - that said, people can also head to rfcs repo in order to familiarize with proposals or send their own.

Describe the session npm open rfc session - will have an agenda composed of the active rfc proposals, recap of state of things in the npm cli, onboard new collaborators.

Session facilitator(s), Github handle(s) and timezone(s) @darcyclarke and @ruyadorno

Additional context (optional) @npm has been holding virtual open rfc meetings in order to better communicate with the broader community and this collaboration session is an opportunity to discuss some of the ongoing topics with active members of the summit while also onboarding new folks that want to participate in the development of the npm cli.


<!-- Thank you for the Session Proposal. You're done! The next section is for logistics and planning only. -->

This section is for contributors handling Collaborator Summit logistics

Track

  • [ ] New Contributor Orientation Track (see #251)
  • [ ] Regular Track
  • [ ] Cross-Project Track

Triage

  • [ ] Track chosen
  • [ ] Scheduled

created time in 11 days

PR closed npm/cli

Correcting isntall

Correcting a typo for the install command

When using the command 'npm install --help', I noticed that in the description 'aliases: i, isntall, add', install is written isntall. I imagine that this is some type of typo, so looking at the code, I made some changes that I believe can help. Thank you.

+2 -3

1 comment

2 changed files

tomazcunha

pr closed time in 11 days

pull request commentnpm/cli

Correcting isntall

thanks @ljharb and @tomazcunha 😊

tomazcunha

comment created time in 11 days

Pull request review commentnpm/rfcs

RFC: npm workspaces - Running Commands

+# npm workspaces: Running commands++## Summary++Introduces basic support to running **npm commands** across nested **workspaces**.++## Motivation++The need for running **npm commands** across nested **workspaces** was sourced from the community during the ellaboration of the [original **npm workspaces** RFC](https://github.com/npm/rfcs/pull/103).++## Detailed Explanation++Following up from the original **npm workspaces** RFC are the following command-related changes:++- A subset of the standard **npm commands** needs to be made aware of **npm workspaces**+- It's desired to have a standard way to filter out **workspaces** in which to run specific **npm commands**++## Rationale and Alternatives++The ability to run **npm commands** across defined **workspaces** is essential to successfully manage a **npm workspaces** workflow. That makes the following alternatives much less desireable:++- Do not implement further support to manage running commands across **workspaces**+- Implement only _some_ of the implementation changes described in this document++**Note:** Alternative ways of executing each of the described features are defined along with their implementation details below.++## Implementation++### 1. Run commands across all child packages++Make **npm cli** subcommands **npm workspaces**-aware, so that running a command tries to run it within all **workspaces** as long as a **workspaces configuration** field is properly defined in `package.json`.++Only a subset of commands are to be supported:++- `fund` List funding info for all **workspaces**+- `ls` List all packages including **workspaces**+- `outdated` List outdated **dependencies** including **workspaces** and its **dependencies**+- `run-script` Run arbitrary **scripts** in all **workspaces**, skip any **workspace** that does not have a targetting **script**+- `rebuild` Rebuild all **workspaces**+- `restart`+- `start`+- `stop`+- `test` Run test **scripts** in all **workspaces**+- `update` Updates a **dependency** across the entire installation tree, including **workspaces**+- `view` View registry info, also including **workspaces**++#### Test example:++```+├── package.json { "name": "foo", "workspaces": ["dep-a", "dep-b"] }+├── dep-a+│   └── package.json { "version": "1.0.0" }+└── dep-b+    └── package.json { "version": "1.3.1" }++$ npm test++> foo@1.0.0 test /Users/username/foo+> echo "Error: no test specified" && exit 1++Error: no test specified+npm ERR! Test failed.  See above for more details.++> dep-a@1.0.0 test /Users/username/foo/dep-a+> done++> dep-b@1.3.1 test /Users/username/foo/dep-b+> done+```++**NOTE:** `publish` and `version` are very special cases in a **npm workspaces** setup and are outside of the scope of this RFC. These features will live in userland in the form of popular modules such as [Lerna](https://lerna.js.org/) for the foreseeable future.++### 2. Filter a subset of workspaces++Filter is done via positional argument and here are some of the reasons why we decided to go that route:+- [Lerna filters](https://www.npmjs.com/package/@lerna/filter-options) were the starting point but early in the discussion some other considerations were brought forward+- npm configs have some baggage, configs might apply to the larger behavior of the cli or to a specific subcommand and they're all mixed together+- defining a subset of workspaces in a `.npmrc` file might be just a footgun leading users into confusion+- Yarn v1 uses positional arguments for filter in the form of `yarn workspace <workspace_name> <cmd>`, so there's precedent++Leading this RFC to a proposal using positional arguments. Rather than defining a strict UX, the current proposal is to adhere to a `workspace` command prefix in the form of either: `npm workspace <workspace_name> <command>` OR `npm ws <workspace_name> <command>` OR an even shorter shortcut using a symbol `npm :<workspace_name> <command>`, for example running `test` in a specific **workspace** named `foo` with these different ideas:++- `npm workspace foo test`+- `npm ws foo test`+- `npm :foo test`++Leaving space to gather feedback from the community on whether to introduce one of this proposed commands or even introducing some novel interface.

this is related to the conversation going on at https://github.com/npm/rfcs/pull/133#issuecomment-621397885 and honestly we might just spin off an RFC/discussion around a new config management system for the cli

ruyadorno

comment created time in 11 days

push eventnpm/arborist

isaacs

commit sha b28a43f002b44292860111004fef6c6bc3a68f0e

Add {complete:true} buildIdealTree option to load sw/bundles Needed for implementing 'npm install --package-lock-only' PR-URL: https://github.com/npm/arborist/pull/73 Credit: @isaacs Close: #73 Reviewed-by: @ruyadorno

view details

push time in 11 days

PR closed npm/arborist

Reviewers
Add {complete:true} buildIdealTree option to load sw/bundles

Needed for implementing 'npm install --package-lock-only'

+580 -58

1 comment

8 changed files

isaacs

pr closed time in 11 days

Pull request review commentnpm/rfcs

RFC: npm workspaces - Running Commands

+# npm workspaces: Running commands++## Summary++Introduces basic support to running **npm commands** across nested **workspaces**.++## Motivation++The need for running **npm commands** across nested **workspaces** was sourced from the community during the ellaboration of the [original **npm workspaces** RFC](https://github.com/npm/rfcs/pull/103).++## Detailed Explanation++Following up from the original **npm workspaces** RFC are the following command-related changes:++- A subset of the standard **npm commands** needs to be made aware of **npm workspaces**+- It's desired to have a standard way to filter out **workspaces** in which to run specific **npm commands**++## Rationale and Alternatives++The ability to run **npm commands** across defined **workspaces** is essential to successfully manage a **npm workspaces** workflow. That makes the following alternatives much less desireable:++- Do not implement further support to manage running commands across **workspaces**+- Implement only _some_ of the implementation changes described in this document++**Note:** Alternative ways of executing each of the described features are defined along with their implementation details below.++## Implementation++### 1. Run commands across all child packages++Make **npm cli** subcommands **npm workspaces**-aware, so that running a command tries to run it within all **workspaces** as long as a **workspaces configuration** field is properly defined in `package.json`.++Only a subset of commands are to be supported:++- `fund` List funding info for all **workspaces**+- `ls` List all packages including **workspaces**+- `outdated` List outdated **dependencies** including **workspaces** and its **dependencies**+- `run-script` Run arbitrary **scripts** in all **workspaces**, skip any **workspace** that does not have a targetting **script**+- `rebuild` Rebuild all **workspaces**+- `restart`+- `start`+- `stop`+- `test` Run test **scripts** in all **workspaces**+- `update` Updates a **dependency** across the entire installation tree, including **workspaces**+- `view` View registry info, also including **workspaces**++#### Test example:++```+├── package.json { "name": "foo", "workspaces": ["dep-a", "dep-b"] }+├── dep-a+│   └── package.json { "version": "1.0.0" }+└── dep-b+    └── package.json { "version": "1.3.1" }++$ npm test++> foo@1.0.0 test /Users/username/foo+> echo "Error: no test specified" && exit 1++Error: no test specified+npm ERR! Test failed.  See above for more details.++> dep-a@1.0.0 test /Users/username/foo/dep-a+> done++> dep-b@1.3.1 test /Users/username/foo/dep-b+> done+```++**NOTE:** `publish` and `version` are very special cases in a **npm workspaces** setup and are outside of the scope of this RFC. These features will live in userland in the form of popular modules such as [Lerna](https://lerna.js.org/) for the foreseeable future.++### 2. Filter a subset of workspaces++Filter is done via positional argument and here are some of the reasons why we decided to go that route:+- [Lerna filters](https://www.npmjs.com/package/@lerna/filter-options) were the starting point but early in the discussion some other considerations were brought forward+- npm configs have some baggage, configs might apply to the larger behavior of the cli or to a specific subcommand and they're all mixed together+- defining a subset of workspaces in a `.npmrc` file might be just a footgun leading users into confusion+- Yarn v1 uses positional arguments for filter in the form of `yarn workspace <workspace_name> <cmd>`, so there's precedent++Leading this RFC to a proposal using positional arguments. Rather than defining a strict UX, the current proposal is to adhere to a `workspace` command prefix in the form of either: `npm workspace <workspace_name> <command>` OR `npm ws <workspace_name> <command>` OR an even shorter shortcut using a symbol `npm :<workspace_name> <command>`, for example running `test` in a specific **workspace** named `foo` with these different ideas:++- `npm workspace foo test`+- `npm ws foo test`+- `npm :foo test`++Leaving space to gather feedback from the community on whether to introduce one of this proposed commands or even introducing some novel interface.++#### Install dependency example:++Add `tap` as a **dependency** of a **workspace** named `foo`:++```sh+npm workspace foo install tap+npm ws foo install tap+npm :foo install tap+```++Note: **Globs** are not supported as a _subset/filter_ argument, the alternative is to use `npm workspace <alias> <cmd>` in which the `alias` can be defined beforehand in your **workspace** configuration as detailed in the next section.++### 3. Grouping/Aliasing workspaces++One proposed feature that was surfaced during our brainstorm sessions is the ability for users to create arbitrary groups of **workspaces** defined via **workspaces configuration**, e.g:++Given a **npm workspace** setup with the following file structure:++```+/root+├── core+│   ├── foo+│   ├── bar+│   └── util+└── plugins+    ├── helpers+    ├── lorem+    └── ipsum+```++It's possible to define a **groups** property within your **workspaces configuration** that will allow defining named sets of **workspaces** that can be later on used to run commands, e.g:++```+{+    "name": "workspace-example",+    "version": "1.0.0",+    "workspaces": {+        "groups": {+            "core": ["core/*"], // accepts fs location+            "plugins": ["lorem", "ipsum"], // also accepts workspaces names+            "common": ["util", "helpers"]+        },+        "packages": [+            "core/*",+            "plugins/*"+        ]+    }+}+```++Following up with the previous configuration example, it would be possible to run tests across all **workspaces** from the `plugins` group, as following:++```+// one of these:+$ npm workspace plugins test+$ npm ws plugins test+$ npm :plugins test++> lorem@1.0.0 test /root/plugins/lorem+> done++> ipsum@1.0.0 test /root/plugins/ipsum+> done+```++Further example, install a **peer dependency** across a group of packages named `core`:++```+$ npm workspace core install react@16 --save-peer+$ npm ws core install react@16 --save-peer+$ npm :core install react@16 --save-peer+```++## Prior Art++#### Previously++- [npm workspaces](https://github.com/npm/rfcs/blob/de8d71c0453f5cf443d3ef2f47e313f12dd6aaf9/accepted/0000-workspaces.md)++#### Filtering a subset of workspaces++- [lerna filter-options](https://www.npmjs.com/package/@lerna/filter-options)+- [Yarn v1 workspace](https://classic.yarnpkg.com/en/docs/cli/workspace)+- [Yarn v2 foreach include/exclude](https://yarnpkg.com/cli/workspaces/foreach)+- [pnpm recursive --filter](https://pnpm.js.org/en/cli/recursive#filter-lt-package_selector)

thanks for sharing that bit of context @zkochan 😊

I see pnpm --filter also supports <directory> (which I suppose maybe also globs along with that?) what I proposed initially in this RFC is to avoid these in favor of a separate "aliases" OR "groups" definition that can also be defined in package.json for ease to share/reuse while also decoupling that categorization from the fs layout

ruyadorno

comment created time in 11 days

Pull request review commentnpm/rfcs

RFC: npm workspaces - Running Commands

+# npm workspaces: Running commands++## Summary++Introduces basic support to running **npm commands** across nested **workspaces**.++## Motivation++The need for running **npm commands** across nested **workspaces** was sourced from the community during the ellaboration of the [original **npm workspaces** RFC](https://github.com/npm/rfcs/pull/103).++## Detailed Explanation++Following up from the original **npm workspaces** RFC are the following command-related changes:++- A subset of the standard **npm commands** needs to be made aware of **npm workspaces**+- It's desired to have a standard way to filter out **workspaces** in which to run specific **npm commands**++## Rationale and Alternatives++The ability to run **npm commands** across defined **workspaces** is essential to successfully manage a **npm workspaces** workflow. That makes the following alternatives much less desireable:++- Do not implement further support to manage running commands across **workspaces**+- Implement only _some_ of the implementation changes described in this document++**Note:** Alternative ways of executing each of the described features are defined along with their implementation details below.++## Implementation++### 1. Run commands across all child packages++Make **npm cli** subcommands **npm workspaces**-aware, so that running a command tries to run it within all **workspaces** as long as a **workspaces configuration** field is properly defined in `package.json`.++Only a subset of commands are to be supported:++- `fund` List funding info for all **workspaces**+- `ls` List all packages including **workspaces**+- `outdated` List outdated **dependencies** including **workspaces** and its **dependencies**+- `run-script` Run arbitrary **scripts** in all **workspaces**, skip any **workspace** that does not have a targetting **script**+- `rebuild` Rebuild all **workspaces**+- `restart`+- `start`+- `stop`+- `test` Run test **scripts** in all **workspaces**+- `update` Updates a **dependency** across the entire installation tree, including **workspaces**+- `view` View registry info, also including **workspaces**++#### Test example:++```+├── package.json { "name": "foo", "workspaces": ["dep-a", "dep-b"] }+├── dep-a+│   └── package.json { "version": "1.0.0" }+└── dep-b+    └── package.json { "version": "1.3.1" }++$ npm test++> foo@1.0.0 test /Users/username/foo+> echo "Error: no test specified" && exit 1++Error: no test specified+npm ERR! Test failed.  See above for more details.++> dep-a@1.0.0 test /Users/username/foo/dep-a+> done++> dep-b@1.3.1 test /Users/username/foo/dep-b+> done+```++**NOTE:** `publish` and `version` are very special cases in a **npm workspaces** setup and are outside of the scope of this RFC. These features will live in userland in the form of popular modules such as [Lerna](https://lerna.js.org/) for the foreseeable future.++### 2. Filter a subset of workspaces++Filter is done via positional argument and here are some of the reasons why we decided to go that route:+- [Lerna filters](https://www.npmjs.com/package/@lerna/filter-options) were the starting point but early in the discussion some other considerations were brought forward+- npm configs have some baggage, configs might apply to the larger behavior of the cli or to a specific subcommand and they're all mixed together+- defining a subset of workspaces in a `.npmrc` file might be just a footgun leading users into confusion+- Yarn v1 uses positional arguments for filter in the form of `yarn workspace <workspace_name> <cmd>`, so there's precedent++Leading this RFC to a proposal using positional arguments. Rather than defining a strict UX, the current proposal is to adhere to a `workspace` command prefix in the form of either: `npm workspace <workspace_name> <command>` OR `npm ws <workspace_name> <command>` OR an even shorter shortcut using a symbol `npm :<workspace_name> <command>`, for example running `test` in a specific **workspace** named `foo` with these different ideas:++- `npm workspace foo test`+- `npm ws foo test`+- `npm :foo test`++Leaving space to gather feedback from the community on whether to introduce one of this proposed commands or even introducing some novel interface.

I really like using a shorter alias such as -w but the reason to steer away from named configs has more to do with the specific npm behavior

ruyadorno

comment created time in 11 days

push eventnpm/arborist

isaacs

commit sha 6f30725b60d157d4ca42457897dc94389a50ba3c

ideal: minor refactoring for clarity in add method

view details

isaacs

commit sha 43254142a21b76d00a3bf5c2293895f1138ded92

test fixture with a v1 shrinkwrap

view details

isaacs

commit sha bcd7e35eaef95490178ce57e181004dd29554796

include pkg name/version in loadVirtual test snapshots Demonstrates root cause problem of #70. The Shrinkwrap class only adds the 'name' field for new lockfiles, but loadVirtual expects it to be there Really, it probably shouldn't be there for v2 lockfiles either, since it's almost always extraneous, except for alias dep types, but regardless, loadVirtual should work out the package name from the folder if it's not present.

view details

isaacs

commit sha 9078b7dd7e526c5ae81e2952b156d03457ebd793

test reify for #70 Demonstrates the issue by showing `"wrappy": "npm:undefined@^1.0.2"` is saved to the package.json incorrectly.

view details

isaacs

commit sha 3f94af2b789c3ac91a70a0bdceb32f100eb8512f

Include name in loadVirtual node.package Fix #70 Reify change is to maintain coverage, since we never have a package version without a name, so there's no need for the fallback to node.name.

view details

isaacs

commit sha c6d9e46fc2e0e18b49e8a637c2863adf38b3da18

Omit name from shrinkwrap when not needed Now that we load the name when creating Node objects in loadVirtual, there's no need to include it in the shrinkwrap metadata entry. PR-URL: https://github.com/npm/arborist/pull/74 Credit: @isaacs Close: #74 Reviewed-by: @ruyadorno

view details

push time in 12 days

PR closed npm/arborist

Isaacs/fix 70

Fix #70

  • Add name to package data when creating Nodes in loadVirtual
  • Tests demonstrating the issue in #70
  • Since we're handling nameless metadata entries, no need to include the name for lockfile entries where the package name and node name match (ie, only for alias deps and cases where the package.json in a url or git dep don't match the path).
+2792 -228

0 comment

16 changed files

isaacs

pr closed time in 12 days

issue closednpm/arborist

[BUG] installing a module as a new dep that is already in the tree saves incorrectly

When calling Arborist.reify({ add: ['pkg'] }), and a version already exists in the tree, it is saved to package.json like:

  "dependencies": {
    "wrappy": "npm:undefined@^1.0.2"
  }

It looks like maybe the node.name isn't being set or something?

closed time in 12 days

isaacs

push eventnpm/arborist

Matt

commit sha ed5f476e2fd497eb313f6deede6a64c6117a8bcd

Trivial spelling correction in README PR-URL: https://github.com/npm/arborist/pull/75 Credit: @mtoothman Close: #75 Reviewed-by: @ruyadorno

view details

push time in 12 days

PR closed npm/arborist

Trivial spelling correction in README

What / Why

Correct spelling of "hierarchy" in three places in main README.

References

<!-- Examples

  • Related to #0
  • Depends on #0
  • Blocked by #0
  • Closes #0 -->
  • n/a
+3 -3

0 comment

1 changed file

mtoothman

pr closed time in 12 days

Pull request review commentnpm/arborist

Add {complete:true} buildIdealTree option to load sw/bundles

 module.exports = cls => class IdealTreeBuilder extends Tracker(Virtual(Actual(cl     // satisfied by whatever's in that file anyway.     if (this[_depsSeen].has(node) ||         node.root !== this.idealTree ||-        node.hasShrinkwrap)+        node.hasShrinkwrap && !this[_complete])       return this[_buildDepStep]()      this[_depsSeen].add(node)     this[_currentDep] = node     process.emit('time', `idealTree:${node.location || '#root'}`) +    // if we're loading a _complete_ ideal tree, for a --package-lock-only+    // installation for example, we have to crack open the tarball and+    // look inside if it has bundle deps or shrinkwraps.  note that this is+    // not necessary during a reification, because we just update the+    // ideal tree by reading bundles/shrinkwraps in place.+    if (this[_complete] && node !== this.idealTree) {+      const Arborist = this.constructor+      const bd = node.package.bundleDependencies+      const hasBundle = bd && Array.isArray(bd) && bd.length+      const { hasShrinkwrap } = node+      if (hasBundle || hasShrinkwrap) {+        const opt = { ...this.options }+        await cacache.tmp.withTmp(this.cache, opt, async path => {+          await pacote.extract(node.resolved, path, opt)++          if (hasShrinkwrap)+            await new Arborist({ ...this.options, path })+              .loadVirtual({ root: node })

wow are these composing install trees? 🤩 is it that easy? it gives me some workspaces ideas...

isaacs

comment created time in 12 days

Pull request review commentnpm/arborist

Add {complete:true} buildIdealTree option to load sw/bundles

     "@npmcli/name-from-folder": "^1.0.1",     "@npmcli/run-script": "^1.3.1",     "bin-links": "^2.1.2",+    "cacache": "^15.0.3",

question: why cacache is only getting added now?

isaacs

comment created time in 12 days

Pull request review commentnpm/arborist

Add {complete:true} buildIdealTree option to load sw/bundles

 class Arborist extends Auditor(require('events')) {       nodeVersion: process.version,       ...options,       path: options.path || '.',+      cache: options.cache || `${homedir()}/.npm/_cacache`,

looks like it would be nicer to have a cacache API that returns the default location instead here 🤔

isaacs

comment created time in 12 days

issue commentnpm/rfcs

Open RFC Meeting - Wednesday, May 13, 2020, 2:00 PM EST

Notes: https://hackmd.io/sTxWRkp2QJiM0WqSDNaI4g?both Video record: https://youtu.be/_veuJrHuERE

darcyclarke

comment created time in 12 days

issue closednpm/rfcs

Open RFC Meeting - Wednesday, May 13, 2020, 2:00 PM EST

Why?

In our ongoing efforts to better listen to & collaborate with the community, we've started an Open RFC call that helps to move conversations & initiatives forward.

When?

Wednesday, May 13, 2020, 2:00 PM EST

Cadence: This meeting is scheduled to take place bi-weekly. Previous meeting agendas and notes can be found here

Add to your Calendar: You follow this & find other npm events by using our public events calendar

What?

All discussions surrounding RFCs are covered by the npm Code of Conduct. Please keep conversations constructive, civil & be mindful of when others are speaking. As is tradition, "raise your hand" when requesting to comment on a topic or request to comment asynchronously within the chat. The npm team may, at its own discretion, moderate, mute &/or remove a person from an Open RFC call for any reason.

Agenda

  1. Housekeeping
    1. Introduction(s)
    2. Code of Conduct Acknowledgement
    3. Outline Intentions & Desired Outcomes
    4. Announcements
  2. PR: #135 Clarify/Outline the RFC Withdrawal Process & Amendment
  3. PR: #133 RFC: Remove --depth from npm outdated
  4. PR: #129 RFC: overrides
  5. PR: #126 RFC: Adding types information to the Package JSON in the registry
  6. PR: #121 Added proposal for package version link#[version] syntax
  7. PR: #117 RFC: npm workspaces - Running Commands

How?

Join Zoom Meeting https://npm.zoom.us/j/584504445

Dial by your location +1 669 900 6833 US (San Jose) +1 646 558 8656 US (New York)

Meeting ID: 584 504 445 Find your local number: https://zoom.us/u/abR8OFljr8

Watch the livestream https://www.youtube.com/channel/UCK71Wk0I45SLTSXQA23GdIw/videos

closed time in 12 days

darcyclarke

push eventruyadorno/rfcs

Ruy Adorno

commit sha 979b995aee373613b37d61f7dddcbed90b532fd4

add feedback about filters from the openrfc call

view details

push time in 12 days

push eventnpm/rfcs

Ruy Adorno

commit sha c4feef61a2134377f6e74bdb9d3d6cd4e66c81bf

chore: add meeting notes

view details

push time in 12 days

startedg-harel/npmfs

started time in 13 days

push eventnpm/cli

Ruy Adorno

commit sha ae03250a4b5461db13f664c1999aa7b462ff3f00

wip

view details

Ruy Adorno

commit sha c73da92b22c21ed2b6e124e6ad76a0608170acd4

wip: new print human output

view details

push time in 13 days

push eventnpm/cli

Ruy Adorno

commit sha becbd971c1c106ea119a68dcf98b246975a870b7

wip: add utils.reify-output fund summary test

view details

Ruy Adorno

commit sha 8c245bd5b8afa97f43b7aa375b5609d9e5920ba8

wip

view details

push time in 14 days

push eventnpm/cli

Ruy Adorno

commit sha 85714978e6bc6aade03a437a56a6efd1c760b0e8

wip: better auditReport conditional

view details

push time in 14 days

push eventnpm/cli

Ruy Adorno

commit sha 4f1e50cbe347136347cb6d2d8f9cfd116e260467

wip

view details

push time in 14 days

more