fix: drop npm dependency

[antongolub]

closes #434 relates #270

alternative #445

https://github.com/semantic-release/npm/issues/434#issuecomment-999870524

Suggestion: remove npm dependency. I still believe that the plugin always invokes global npm, so this dependency is completely useless.

Have a look:

https://github.com/semantic-release/npm/blob/708c29bf735d731f6855b2425ba9f12b618873dd/lib/publish.js#L23

npm is called via execa. It is just a wrapper for child_process.exec by default. cp uses $PATH to find util ref, and it knows absolutely nothing about node_modules/.bin/npm.

git clone ... && npm i
npm -v
6.14.13

node -e "console.log(require('execa').sync('npm', ['-v']).stdout)"
6.14.13

node -e "console.log(require('./node_modules/npm/package.json').version)"
7.24.2

if we want execa to call the plugins's own npm version, we should pass preferlocal option.

node -e "console.log(require('execa').sync('npm', ['-v'], {preferLocal: true}).stdout)"
7.24.2

[the-spyke]

Please merge this. If there's a necessity to have a specific npm, it could be done through the engines property.

[antongolub]

Closed in favor of https://github.com/semantic-release/npm/pull/445

[antongolub]

I've recognised that some package may bring its own npm version if needed. Reopened.

[the-spyke]

#445 Does not replace this. I don't want to see npm and it's tree in the lock file. If you don't want to drop it please make it a peerDependency

[schmidtk]

This dependency causes an unfortunate side effect in projects using npm workspaces, because the npm dependency from this package gets hoisted to the root node_modules. Scripts using npm run will then use the locally installed version of npm from this package instead of the global install.

I described the issue in further detail here: https://github.com/npm/rfcs/issues/287#issuecomment-1177959216

Is the dependency truly needed in this package, or can it be either removed or made a peer dependency? Thanks for you time.

[travi]

can it be either removed or made a peer dependency?

our recommendation is to execute semantic-release using npx so that semantic-release is only installed at execution time and not defined in your package.json or your lockfile. this will limit the impact of npm being installed as a dependency as well

This dependency causes an unfortunate side effect in projects using npm workspaces

this project does not officially support use in monorepos, so impacts to workspaces are officially out of scope. what additional tooling are you using in your project to enable use within a monorepo?

[the-spyke]

our recommendation is to execute semantic-release using npx so that semantic-release is only installed at execution time and not defined in your package.json or your lockfile.

I don't want to use npx so everything is stable and hash-verified without hacking around npm caches on CI.

[travi]

I don't want to use npx so everything is stable and hash-verified without hacking around npm caches on CI.

you are welcome to make that choice, but that means living with the current trade-offs. we are not ready to make a decision on this change, but are considering the impacts. in the meantime, those are the available options.

[schmidtk]

our recommendation is to execute semantic-release using npx so that semantic-release is only installed at execution time and not defined in your package.json or your lockfile. this will limit the impact of npm being installed as a dependency as well

I'll look into the global install route to avoid bloating our package lock, though we prefer the local installation for the same reasons @the-spyke identified.

this project does not officially support use in monorepos, so impacts to workspaces are officially out of scope. what additional tooling are you using in your project to enable use within a monorepo?

We wrote a simple script that gathers workspace projects with semantic-release configured and runs npm run semantic-release --workspace=<project> on each of them.

[jcnix]

I'm going to bump this because there is a CVE right now affecting npm so anyone who uses this package which pulls in npm and its tree get a High severity vulnerability tagged to them. npm bundles their dependencies so their is currently no solution other than waiting for an npm update, you cannot override the offending package via npm audit fix

https://github.com/advisories/GHSA-78xj-cgh5-2h22

[gr2m]

regarding the CVE, see our recommendation above: https://github.com/semantic-release/npm/pull/444#issuecomment-1178249870