From 12fe87710ae79bec83d5aff34733289dce1b36ba Mon Sep 17 00:00:00 2001 From: Owen Buckley Date: Wed, 25 May 2022 09:07:34 -0400 Subject: [PATCH 1/7] first draft --- accepted/0000-registry-only-tarballs.md | 107 ++++++++++++++++++++++++ 1 file changed, 107 insertions(+) create mode 100644 accepted/0000-registry-only-tarballs.md diff --git a/accepted/0000-registry-only-tarballs.md b/accepted/0000-registry-only-tarballs.md new file mode 100644 index 000000000..94054d724 --- /dev/null +++ b/accepted/0000-registry-only-tarballs.md @@ -0,0 +1,107 @@ +### References +relates to #581 + +---- + +# Registry Only Tarballs + +## Summary + +When installing dependencies, the npm CLI should have a mechanism for communicating (and optionally failing on) dependencies that do not come from a registry, like a [git URL](https://docs.npmjs.com/cli/v7/configuring-npm/package-json#git-urls-as-dependencies). + +## Motivation + +In an effort to give users of npm more insight and transparency into the packages they are installing, knowing that a package is _not_ coming from a registry, and thus is susceptible to mutability and related supply chain attacks from that vector, seems like a meaningful heuristic missing from the package manager. + +Thus, npm should afford various levels of messaging and erroring through a flag to accommodate users of npm looking to gain this insight from their dependency graph. + +## Detailed Explanation + +For example a _package.json_ like this +```json +{ + "dependencies": { + "@babel/cli": "^7.4.0", + "eslint": "git+https://github.com/eslint/eslint.git" + } +} +``` + +Would trigger a message to the console for **eslint** if the `warn` value was passed. + +```sh +$ npm install --only-registry-tarballs=warn +``` + +## Rationale and Alternatives + +It could be argued that a user could write a script themselves that does all the look-ups and resolution from a given _package.json_ to vet their dependencies that way, potentially reusing arborist in a similar manner to how the CLI uses it. + +However, when this issue was raised no other alternatives were suggested at the time, even the one above, so it seems that most feel (implicitly at least) that the package manager is in the best position to vet the location of dependencies before they can be installed, and communicate that information to the user. + +## Implementation + +As npm is building up the dependency graph, it should check if _any_ dependency in the tree is not using a valid [semver range](https://docs.npmjs.com/cli/v7/configuring-npm/package-json#dependencies) and emit a message to the user in the terminal. + +The flag would allow three values that the user could be provided based on the outcome of messaging / behavior the user was looking for: +```sh +$ npm install --only-registry-tarballs=silent|warn|fail +``` + +### Silent (default) +Same behavior as it is now in the CLI, which is effectively that there is no consideration made for the location of a dependency. This would be the default value of the flag as far as the npm CLI is concerned, or if the user used the flag but and did not pass any value. + +```sh +# both would behave the same way +$ npm install --only-registry-tarballs +$ npm install --only-registry-tarballs=silent +``` + +### Warn +Emits a `console.log` to the terminal indicating that a dependency is installing via a non-registry URL. + +```sh +$ npm install --only-registry-tarballs=warn +npm WARN deprecated coffee-script@1.12.7: CoffeeScript on NPM has moved to "coffeescript" (no hyphen) +npm WARN eslint NOT installed from a registry, using tarball URL + +added xxx packages, and audited xxx packages in 8s + +... +``` + +### Fail +Emits a `console.error` to the terminal indicating that a dependency is installing via a non-registry URL AND then exits the process with an exit code. + +```sh +$ npm install --only-registry-tarballs=error +npm WARN deprecated coffee-script@1.12.7: CoffeeScript on NPM has moved to "coffeescript" (no hyphen) +npm ERROR eslint NOT installed from a registry, using tarball URL + +process exited with code .... +``` + +---- + +Additionally, this behavior should probably captured in relevant area(s) of the documentation, likely in the dependencies section of the docs, where non semver range versions are discussed. + +## Prior Art + +As far as I know, while other package managers allow installing from URLs and git repositories, none of them call it out as a potential anti-pattern or area of caution. +- **yarn**: [`add`](https://classic.yarnpkg.com/en/docs/cli/add#toc-adding-dependencies), [`install`](https://yarnpkg.com/cli/install) +- **pnpm**: [`add`](https://pnpm.io/cli/add#install-from-git-repository), [`install`](https://pnpm.io/cli/install) + +This seems like a worthwhile area for npm to be the first mover. + +## Unresolved Questions and Bikeshedding + +### Default Behavior +As proposed, the default behavior would be the `silent` option. As part of a semver-major change, the default behavior could be changed to that of the `warn` option instead. + +### Dependency Distinctions +A point raised was if different dependency types should have different rules applied to them, or if this flag should apply equally across direct and transitive dependencies alike. ex. +- warn by default for direct dependencies +- hide by default for transitive dependencies + +### Naming +Currently the flag is `--only-registry-tarballs` which while explicit, is a bit verbose. I think the final flag name is less consequential / material to the ultimate objective of this RFC, as long as it gets clearly captured in relevant areas of the documentation. \ No newline at end of file From 25590578db1851423f3fd0648dc09598b27f72df Mon Sep 17 00:00:00 2001 From: Owen Buckley Date: Mon, 20 Jun 2022 10:44:53 -0400 Subject: [PATCH 2/7] first round PR and meeting notes feedback --- accepted/0000-registry-only-tarballs.md | 107 +++++++++++++++++------- 1 file changed, 78 insertions(+), 29 deletions(-) diff --git a/accepted/0000-registry-only-tarballs.md b/accepted/0000-registry-only-tarballs.md index 94054d724..862ef5967 100644 --- a/accepted/0000-registry-only-tarballs.md +++ b/accepted/0000-registry-only-tarballs.md @@ -7,11 +7,11 @@ relates to #581 ## Summary -When installing dependencies, the npm CLI should have a mechanism for communicating (and optionally failing on) dependencies that do not come from a registry, like a [git URL](https://docs.npmjs.com/cli/v7/configuring-npm/package-json#git-urls-as-dependencies). +When auditing dependencies with `npm audit`, the npm CLI should have a mechanism for communicating (and optionally failing on) dependencies that do not come from a registry, like a [git URL](https://docs.npmjs.com/cli/v7/configuring-npm/package-json#git-urls-as-dependencies). ## Motivation -In an effort to give users of npm more insight and transparency into the packages they are installing, knowing that a package is _not_ coming from a registry, and thus is susceptible to mutability and related supply chain attacks from that vector, seems like a meaningful heuristic missing from the package manager. +In an effort to give users of npm more insight and transparency into the packages they are installing, knowing that a package is _not_ coming from a registry and thus is susceptible to mutability and related supply chain attacks from that vector, seems like a meaningful heuristic missing from the package manager. Thus, npm should afford various levels of messaging and erroring through a flag to accommodate users of npm looking to gain this insight from their dependency graph. @@ -27,63 +27,101 @@ For example a _package.json_ like this } ``` -Would trigger a message to the console for **eslint** if the `warn` value was passed. +Would trigger a message to the console for **eslint** if the `warn` value was passed when running `npm audit`. ```sh -$ npm install --only-registry-tarballs=warn +$ npm audit --only-non-remote-deps=warn + +found 1 vulnerabilities + +... ``` ## Rationale and Alternatives -It could be argued that a user could write a script themselves that does all the look-ups and resolution from a given _package.json_ to vet their dependencies that way, potentially reusing arborist in a similar manner to how the CLI uses it. +It could be argued that a user could write a script themselves that does all the look-ups and resolution from a given _package.json_ or _package-lock.json_ to vet their dependencies that way, potentially reusing arborist in a similar manner to how the CLI uses it. -However, when this issue was raised no other alternatives were suggested at the time, even the one above, so it seems that most feel (implicitly at least) that the package manager is in the best position to vet the location of dependencies before they can be installed, and communicate that information to the user. +However, when this issue was raised no other alternatives were suggested at the time, even the one above, so it seems that most feel (implicitly at least) that the package manager is in the best position to vet the source of dependencies before they can be installed, and communicate that information to the user. ## Implementation -As npm is building up the dependency graph, it should check if _any_ dependency in the tree is not using a valid [semver range](https://docs.npmjs.com/cli/v7/configuring-npm/package-json#dependencies) and emit a message to the user in the terminal. +When running `npm audit`, the user should be informed if _any_ dependency in the tree is not using a valid [semver range](https://docs.npmjs.com/cli/v7/configuring-npm/package-json#dependencies) and emit a message to the terminal communicating that information. + +The flag would allow three values that the user could use to influence the level of messaging and command line behavior: +```sh +$ npm audit --only-non-remote-deps=silent|warn|fail + +found N vulnerabilities + +... +``` + +### Options + +#### Silent +Same behavior as it is now in the CLI effectively, in that there is no messaging in regards to the source of a dependency. -The flag would allow three values that the user could be provided based on the outcome of messaging / behavior the user was looking for: ```sh -$ npm install --only-registry-tarballs=silent|warn|fail +$ npm audit --only-non-remote-deps=silent ``` -### Silent (default) -Same behavior as it is now in the CLI, which is effectively that there is no consideration made for the location of a dependency. This would be the default value of the flag as far as the npm CLI is concerned, or if the user used the flag but and did not pass any value. +#### Warn (default) +Emits a log message to the terminal indicating that a dependency is referencing a non-registry URL. +```sh +$ npm audit --only-non-remote-deps=warn + +found 1 vulnerabilities + +npm WARN eslint is not installed from a trusted source; using tarball URL . Please read more about our guidelines at https://docs.npmjs.com/cli/.... +``` +This would be the default value for the command with or without a value passed to the flag. ```sh # both would behave the same way -$ npm install --only-registry-tarballs -$ npm install --only-registry-tarballs=silent +$ npm audit --only-non-remote-deps +$ npm audit --only-non-remote-deps=warn ``` -### Warn -Emits a `console.log` to the terminal indicating that a dependency is installing via a non-registry URL. +#### Fail +Emits an error level log to the terminal indicating that a dependency has a non-registry URL AND exits the process with an exit code. ```sh -$ npm install --only-registry-tarballs=warn -npm WARN deprecated coffee-script@1.12.7: CoffeeScript on NPM has moved to "coffeescript" (no hyphen) -npm WARN eslint NOT installed from a registry, using tarball URL +$ npm audit --only-non-remote-deps=fail -added xxx packages, and audited xxx packages in 8s +found 1 vulnerabilities -... +npm ERROR eslint is not installed from a trusted source; using tarball URL . Please read more about our guidelines at https://docs.npmjs.com/cli/.... ``` -### Fail -Emits a `console.error` to the terminal indicating that a dependency is installing via a non-registry URL AND then exits the process with an exit code. +### Messaging +In addition to calling out these types of specifiers numerically, it would be good to have the messaging include information about the dependency graph, similar to the `npm why` or `npm explain`. This is important as users will want to be able to use `overrides` for those cases which they don't have direct control over and / or report upstream. + +For example, using the above **eslint** example, a more complete output might look like this: ```sh -$ npm install --only-registry-tarballs=error -npm WARN deprecated coffee-script@1.12.7: CoffeeScript on NPM has moved to "coffeescript" (no hyphen) -npm ERROR eslint NOT installed from a registry, using tarball URL +$ npm audit --only-non-remote-deps=warn + +found 1 vulnerabilities -process exited with code .... +npm WARN eslint is not installed from a trusted source; using tarball URL . Please read more about our guidelines at https://docs.npmjs.com/cli/.... + +eslint@6.8.0 dev +node_modules/eslint + dev eslint@"^6.8.0" from the root project + +... ``` ----- +### Install +It is understood that `npm install` leverages `npm audit` but I believe the output of `npm audit` does not directly influence the behavior of `npm install`, say in the case using the `fail` option here. + +If possible, it would be great for `npm install` to fail if `npm audit` fails. +```sh +$ npm install --fail-on-audit +``` -Additionally, this behavior should probably captured in relevant area(s) of the documentation, likely in the dependencies section of the docs, where non semver range versions are discussed. +### Documentation +In addition to being added to the `npm audit` docs, this behavior should probably be called out or referenced in other relevant area(s) of the CLI documentation, specifically in the [dependencies section of the docs](https://docs.npmjs.com/cli/v7/configuring-npm/package-json#git-urls-as-dependencies), where non semver range versions like git URLs are discussed. ## Prior Art @@ -98,10 +136,21 @@ This seems like a worthwhile area for npm to be the first mover. ### Default Behavior As proposed, the default behavior would be the `silent` option. As part of a semver-major change, the default behavior could be changed to that of the `warn` option instead. +> _Decided that `warn` would be the appropriate initial default._ + ### Dependency Distinctions A point raised was if different dependency types should have different rules applied to them, or if this flag should apply equally across direct and transitive dependencies alike. ex. - warn by default for direct dependencies - hide by default for transitive dependencies +- etc + +> _Decided that the upcoming `npm query` RFC would be the appropriate way to overlay more granular filtering and preferences. Through this, `npm audit` could become over more powerful by elevating this RFC to signal other potential risks like for:_ +> - CVEs (default) +> - Signatures +> - Engines +> - Peer Deps, et al ### Naming -Currently the flag is `--only-registry-tarballs` which while explicit, is a bit verbose. I think the final flag name is less consequential / material to the ultimate objective of this RFC, as long as it gets clearly captured in relevant areas of the documentation. \ No newline at end of file +Currently the flag is `--only-registry-tarballs` which while explicit, is a bit verbose. I think the final flag name is less consequential / material to the ultimate objective of this RFC, as long as it gets clearly captured in relevant areas of the documentation. + +> _Decided on a name of `--only-non-remote-deps` to account for local linking of packages done by a user intentionally._ \ No newline at end of file From 1434771cbe08389add720737a35d66a5c8419592 Mon Sep 17 00:00:00 2001 From: Owen Buckley Date: Sun, 31 Jul 2022 12:59:26 -0400 Subject: [PATCH 3/7] apply feedback to delegate the underlying implementation to be based on npm query --- accepted/0000-registry-only-tarballs.md | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/accepted/0000-registry-only-tarballs.md b/accepted/0000-registry-only-tarballs.md index 862ef5967..680e0b6dd 100644 --- a/accepted/0000-registry-only-tarballs.md +++ b/accepted/0000-registry-only-tarballs.md @@ -9,6 +9,8 @@ relates to #581 When auditing dependencies with `npm audit`, the npm CLI should have a mechanism for communicating (and optionally failing on) dependencies that do not come from a registry, like a [git URL](https://docs.npmjs.com/cli/v7/configuring-npm/package-json#git-urls-as-dependencies). +> _**Note**: this RFC has a hard dependency on [`npm query`](https://github.com/npm/cli/pull/5000) landing to support its implementation._ + ## Motivation In an effort to give users of npm more insight and transparency into the packages they are installing, knowing that a package is _not_ coming from a registry and thus is susceptible to mutability and related supply chain attacks from that vector, seems like a meaningful heuristic missing from the package manager. @@ -45,7 +47,7 @@ However, when this issue was raised no other alternatives were suggested at the ## Implementation -When running `npm audit`, the user should be informed if _any_ dependency in the tree is not using a valid [semver range](https://docs.npmjs.com/cli/v7/configuring-npm/package-json#dependencies) and emit a message to the terminal communicating that information. +When running `npm audit`, the user should be informed if _any_ dependency in the tree is not using a valid [semver range](https://docs.npmjs.com/cli/v7/configuring-npm/package-json#dependencies) and emit a message to the terminal communicating that information. Effectively, the audit messaging should get raised if any of the dependencies qualify as a [`type` of **git** or **remote* dependency per this document](https://github.com/npm/npm-package-arg#result-object). The flag would allow three values that the user could use to influence the level of messaging and command line behavior: ```sh @@ -56,6 +58,11 @@ found N vulnerabilities ... ``` +From a CLI perspective, this could easily (ideally) be delegated to the `npm query` command. +```sh +$ npm query ":root > *:is(:type(git,remote))" +``` + ### Options #### Silent @@ -131,6 +138,8 @@ As far as I know, while other package managers allow installing from URLs and gi This seems like a worthwhile area for npm to be the first mover. +To demonstrate, if you see [this demo repo](https://github.com/thescientist13/npm-query-registry-only-deps-rfc-demo) and follow the steps to `npm link` with a version that has `npm query`, you will see output for **eslint** but not **babel**, which is the desired outcome in this situation given that _package.json_ has eslint as a `git` dependency. + ## Unresolved Questions and Bikeshedding ### Default Behavior From fa5cf746499080ed97d81738ff9b0152273df464 Mon Sep 17 00:00:00 2001 From: Owen Buckley Date: Sun, 31 Jul 2022 13:03:00 -0400 Subject: [PATCH 4/7] refine flag name from only-non-remote-deps to only-registry-deps --- accepted/0000-registry-only-tarballs.md | 24 +++++++++++++----------- 1 file changed, 13 insertions(+), 11 deletions(-) diff --git a/accepted/0000-registry-only-tarballs.md b/accepted/0000-registry-only-tarballs.md index 680e0b6dd..aa8005d01 100644 --- a/accepted/0000-registry-only-tarballs.md +++ b/accepted/0000-registry-only-tarballs.md @@ -3,11 +3,11 @@ relates to #581 ---- -# Registry Only Tarballs +# Registry Only Dependencies ## Summary -When auditing dependencies with `npm audit`, the npm CLI should have a mechanism for communicating (and optionally failing on) dependencies that do not come from a registry, like a [git URL](https://docs.npmjs.com/cli/v7/configuring-npm/package-json#git-urls-as-dependencies). +When auditing dependencies with `npm audit`, the npm CLI should have a mechanism for communicating (and optionally failing on) dependencies that _do not_ come from a registry, like a [git URL](https://docs.npmjs.com/cli/v7/configuring-npm/package-json#git-urls-as-dependencies). > _**Note**: this RFC has a hard dependency on [`npm query`](https://github.com/npm/cli/pull/5000) landing to support its implementation._ @@ -32,7 +32,7 @@ For example a _package.json_ like this Would trigger a message to the console for **eslint** if the `warn` value was passed when running `npm audit`. ```sh -$ npm audit --only-non-remote-deps=warn +$ npm audit --only-registry-deps=warn found 1 vulnerabilities @@ -51,7 +51,7 @@ When running `npm audit`, the user should be informed if _any_ dependency in the The flag would allow three values that the user could use to influence the level of messaging and command line behavior: ```sh -$ npm audit --only-non-remote-deps=silent|warn|fail +$ npm audit --only-registry-deps=silent|warn|fail found N vulnerabilities @@ -69,13 +69,13 @@ $ npm query ":root > *:is(:type(git,remote))" Same behavior as it is now in the CLI effectively, in that there is no messaging in regards to the source of a dependency. ```sh -$ npm audit --only-non-remote-deps=silent +$ npm audit --only-registry-deps=silent ``` #### Warn (default) Emits a log message to the terminal indicating that a dependency is referencing a non-registry URL. ```sh -$ npm audit --only-non-remote-deps=warn +$ npm audit --only-registry-deps=warn found 1 vulnerabilities @@ -85,15 +85,15 @@ npm WARN eslint is not installed from a trusted source; using tarball URL . This would be the default value for the command with or without a value passed to the flag. ```sh # both would behave the same way -$ npm audit --only-non-remote-deps -$ npm audit --only-non-remote-deps=warn +$ npm audit --only-registry-deps +$ npm audit --only-registry-deps=warn ``` #### Fail Emits an error level log to the terminal indicating that a dependency has a non-registry URL AND exits the process with an exit code. ```sh -$ npm audit --only-non-remote-deps=fail +$ npm audit --only-registry-deps=fail found 1 vulnerabilities @@ -106,7 +106,7 @@ In addition to calling out these types of specifiers numerically, it would be go For example, using the above **eslint** example, a more complete output might look like this: ```sh -$ npm audit --only-non-remote-deps=warn +$ npm audit --only-registry-deps=warn found 1 vulnerabilities @@ -162,4 +162,6 @@ A point raised was if different dependency types should have different rules app ### Naming Currently the flag is `--only-registry-tarballs` which while explicit, is a bit verbose. I think the final flag name is less consequential / material to the ultimate objective of this RFC, as long as it gets clearly captured in relevant areas of the documentation. -> _Decided on a name of `--only-non-remote-deps` to account for local linking of packages done by a user intentionally._ \ No newline at end of file +> _Decided on a name of `--only-non-remote-deps` to account for local linking of packages done by a user intentionally._ +> +> _Another name change made to call the flag `--only-registry-deps`._ \ No newline at end of file From 33dad506c2c97c2b8757b8afb5d711835dbf7bb6 Mon Sep 17 00:00:00 2001 From: Owen Buckley Date: Sun, 31 Jul 2022 13:06:14 -0400 Subject: [PATCH 5/7] rename RFC filename --- ...gistry-only-tarballs.md => 0000-registry-only-dependencies.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename accepted/{0000-registry-only-tarballs.md => 0000-registry-only-dependencies.md} (100%) diff --git a/accepted/0000-registry-only-tarballs.md b/accepted/0000-registry-only-dependencies.md similarity index 100% rename from accepted/0000-registry-only-tarballs.md rename to accepted/0000-registry-only-dependencies.md From d361131e73c8fb364a35fe8c385b83ff7ab74509 Mon Sep 17 00:00:00 2001 From: Owen Buckley Date: Mon, 15 Aug 2022 13:15:17 -0400 Subject: [PATCH 6/7] refine npm query example per PR feedback --- accepted/0000-registry-only-dependencies.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/accepted/0000-registry-only-dependencies.md b/accepted/0000-registry-only-dependencies.md index aa8005d01..250f39a5b 100644 --- a/accepted/0000-registry-only-dependencies.md +++ b/accepted/0000-registry-only-dependencies.md @@ -60,7 +60,7 @@ found N vulnerabilities From a CLI perspective, this could easily (ideally) be delegated to the `npm query` command. ```sh -$ npm query ":root > *:is(:type(git,remote))" +$ npm query ":is(:type(git,remote))" ``` ### Options From 096f872a0c69303d8f40e40fc75b37132bab87c2 Mon Sep 17 00:00:00 2001 From: Owen Buckley Date: Mon, 22 Aug 2022 20:32:07 -0400 Subject: [PATCH 7/7] notes and bikeshedding clean up post ratification --- accepted/0000-registry-only-dependencies.md | 35 +-------------------- 1 file changed, 1 insertion(+), 34 deletions(-) diff --git a/accepted/0000-registry-only-dependencies.md b/accepted/0000-registry-only-dependencies.md index 250f39a5b..c12a4aad8 100644 --- a/accepted/0000-registry-only-dependencies.md +++ b/accepted/0000-registry-only-dependencies.md @@ -1,16 +1,9 @@ -### References -relates to #581 - ----- - # Registry Only Dependencies ## Summary When auditing dependencies with `npm audit`, the npm CLI should have a mechanism for communicating (and optionally failing on) dependencies that _do not_ come from a registry, like a [git URL](https://docs.npmjs.com/cli/v7/configuring-npm/package-json#git-urls-as-dependencies). -> _**Note**: this RFC has a hard dependency on [`npm query`](https://github.com/npm/cli/pull/5000) landing to support its implementation._ - ## Motivation In an effort to give users of npm more insight and transparency into the packages they are installing, knowing that a package is _not_ coming from a registry and thus is susceptible to mutability and related supply chain attacks from that vector, seems like a meaningful heuristic missing from the package manager. @@ -138,30 +131,4 @@ As far as I know, while other package managers allow installing from URLs and gi This seems like a worthwhile area for npm to be the first mover. -To demonstrate, if you see [this demo repo](https://github.com/thescientist13/npm-query-registry-only-deps-rfc-demo) and follow the steps to `npm link` with a version that has `npm query`, you will see output for **eslint** but not **babel**, which is the desired outcome in this situation given that _package.json_ has eslint as a `git` dependency. - -## Unresolved Questions and Bikeshedding - -### Default Behavior -As proposed, the default behavior would be the `silent` option. As part of a semver-major change, the default behavior could be changed to that of the `warn` option instead. - -> _Decided that `warn` would be the appropriate initial default._ - -### Dependency Distinctions -A point raised was if different dependency types should have different rules applied to them, or if this flag should apply equally across direct and transitive dependencies alike. ex. -- warn by default for direct dependencies -- hide by default for transitive dependencies -- etc - -> _Decided that the upcoming `npm query` RFC would be the appropriate way to overlay more granular filtering and preferences. Through this, `npm audit` could become over more powerful by elevating this RFC to signal other potential risks like for:_ -> - CVEs (default) -> - Signatures -> - Engines -> - Peer Deps, et al - -### Naming -Currently the flag is `--only-registry-tarballs` which while explicit, is a bit verbose. I think the final flag name is less consequential / material to the ultimate objective of this RFC, as long as it gets clearly captured in relevant areas of the documentation. - -> _Decided on a name of `--only-non-remote-deps` to account for local linking of packages done by a user intentionally._ -> -> _Another name change made to call the flag `--only-registry-deps`._ \ No newline at end of file +To demonstrate, if you see [this demo repo](https://github.com/thescientist13/npm-query-registry-only-deps-rfc-demo) and follow the steps to `npm link` with a version that has `npm query`, you will see output for **eslint** but not **babel**, which is the desired outcome in this situation given that _package.json_ has eslint as a `git` dependency. \ No newline at end of file