Open robertsLando opened 3 years ago
Hello! npm is integrated to Node.JS. NPM 7.x is integrated to Node.JS 15.x. If you specify Node.JS 15.x, NPM 7 will be selected. See details on https://nodejs.org/en/download/releases/
If you need npm 7 for previous versions of Node.JS, please consider upgrading it in runtime via npm install -g npm@latest
@maxim-lobanov Would it be possible to make it configurable like I suggested by using an option? It would allow to easily use matrix too
Is it not enough to add npm_version
to the matrix and manipulate the workflow? I don't think it's a good idea to add more input than necessary.
npm publish doesn't work with node 15.x in github actions:
npm ERR! code ENEEDAUTH
npm ERR! need auth This command requires you to be logged in.
npm ERR! need auth You need to authorize this machine using `npm adduser`
when I downgrade to node 12 it works again
Hello @mendrik , the issue with publishing is caused by updating npm to 7th version in node 15. The first minor and patch version of npm 7th had the issue with _auth. It was fixed in next versions. You can use npm with node 12th or upgrade npm to the latest one npm install -g npm@latest
It seems setting node-version: 15
now gets a release with the proper fix. It is working without having to update npm
Just like we have an option to use node
versions, we should also have an option to choose npm
versions
Using npm install -g npm@latest
with Github Actions gives errors regarding write-access permissions. Installing locally npm i npm@latest
will change the repository and mess up any actions that depend on a clean git repo. Any ideas on how to fix this? How can I use npm@7 with node@14? Using node@15 is not an option, sorry...
What about doing with sudo?
@smorimoto I don't know why I didn't think about it! So, running sudo i -g npm@latest
after setup-node
action does nothing...
Here's part of the log (can't provide a link to the full log because it's a private repo):
2021-03-10T18:20:25.6852244Z ##[group]Run sudo npm i -g npm@latest
2021-03-10T18:20:25.6852862Z sudo npm i -g npm@latest
2021-03-10T18:20:25.6906055Z shell: /usr/bin/bash -e {0}
2021-03-10T18:20:25.6906509Z env:
2021-03-10T18:20:25.6906931Z node-version: 14
2021-03-10T18:20:25.6907390Z ##[endgroup]
2021-03-10T18:20:37.6677894Z /usr/local/bin/npm -> /usr/local/lib/node_modules/npm/bin/npm-cli.js
2021-03-10T18:20:37.6683622Z /usr/local/bin/npx -> /usr/local/lib/node_modules/npm/bin/npx-cli.js
2021-03-10T18:20:37.7550998Z + npm@7.6.2
2021-03-10T18:20:37.7552906Z added 59 packages from 24 contributors, removed 241 packages and updated 194 packages in 10.209s
2021-03-10T18:20:37.7743170Z ##[group]Run echo npm version "$(npm --version)"
2021-03-10T18:20:37.7743827Z echo npm version "$(npm --version)"
2021-03-10T18:20:37.7744307Z echo node version "$(node --version)"
2021-03-10T18:20:37.7790961Z shell: /usr/bin/bash -e {0}
2021-03-10T18:20:37.7791313Z env:
2021-03-10T18:20:37.7791661Z node-version: 14
2021-03-10T18:20:37.7792014Z ##[endgroup]
2021-03-10T18:20:38.3912711Z npm version 6.14.11
2021-03-10T18:20:38.3966163Z node version v14.16.0
You can see that after updating npm
to version 7, GitHub Actions still uses version 6. Any ideas what to do?
I've never had to use sudo
before when working with nvm
. I'm wondering if updating npm
with sudo
did it for the system installed version and not the one used by nvm? In order to update the nvm
one, we might need to run the command without sudo
but that gives us errors about writing permissions...
SOLUTION: After some trial and error, I figure it out. Updating npm
before using this action requires sudo
but updating it after using this action doesn't require sudo
. As I suspected, when running the command with sudo
the system version gets updated, not the one use by this action. So for anybody having the same problem as me, make sure you update npm
AFTER running this action and without using sudo
I suspect that the path priority is wrong. The following command should tell you the order, but it probably shows the one installed by the action at the top.
which --all npm
If it's true, you need to change the priority, but it can be a little tricky. For example, create a new directory, create a symbolic link to npm, and add it to the path through the Actions command.
SOLUTION: After some trial and error, I figure it out. Updating npm before using this action requires sudo but updating it after using this action doesn't require sudo. As I suspected, when running the command with sudo the system version gets updated, not the one use by this action. So for anybody having the same problem as me, make sure you update npm AFTER running this action and without using sudo
Oh, it's good.
Run npm install -g npm@7.11.2
npm ERR! code E404
npm ERR! 404 Not Found - GET https://npm-proxy.fury.io/***/***/npm - bad_request
npm ERR! 404
npm ERR! 404 'npm@7.11.2' is not in the npm registry.
Solution
- name: npm 7
run: npm i -g npm@7 --registry=https://registry.npmjs.org
I'd be -1
on making this a feature in setup-node. We ship a specific version of npm in node.js and it is a one liner to get the latest version of npm (rather than having to keep / manage npm version as part of this action).
run: npm i -g npm@7
Customers should either get the version of npm that ships with Node.js or the latest version on the registry. There would be no way to guarantee the latter if the action itself managed the version of npm. It also is the exact same amount of lines of code to do it either way in the configuration.
One thing we could perhaps do document this pattern? This might also be useful if folks want to downgrade npm... e.g. use npm 6 with Node.js 16
If it helps anybody, I'm currently working around this by using npx
to run a different version of npm
:
run: npx npm@7 i
run: npx npm@7 i
I highly highly advise against using npx
to run npm. There is no advantage, imho, to doing this. npx
will still download the full version of npm, so it isn't any faster... and you risk weird edge cases like npm@7
being used to install but npm@6
being used to run scripts later in the life cycle.
run: npm i -g npm@7
The above is the exact same number of lines as the above suggestion and will result in a consistent version of npm being used across the workflow
I highly highly advise against using
npx
to run npm. There is no advantage, imho, to doing this.npx
will still download the full version of npm, so it isn't any faster... and you risk weird edge cases likenpm@7
being used to install butnpm@6
being used to run scripts later in the life cycle.run: npm i -g npm@7
The above is the exact same number of lines as the above suggestion and will result in a consistent version of npm being used across the workflow
True, I do it this way β https://github.com/geospoc/v-mapbox/blob/main/.github/workflows/ci.yml#L34-L35
till we get an option to select npm
version
// edit: a better approach with inbuilt caching β https://github.com/vinayakkulkarni/v-tweakpane/blob/main/.github/workflows/ci.yml#L52-L55
For folks who would prefer to be able to use specific versions of these, for instance for build reproducibility, you might want to consider using Volta instead. It allows you to pin specific versions of each tool, and it has an action, available here: https://github.com/volta-cli/action
the issue with
run: npm i -g npm@7
is that npm itself won't be in the cache π’
@MylesBorins:
I'd be
-1
on making this a feature in setup-node. We ship a specific version of npm in node.js and it is a one liner to get the latest version of npm (rather than having to keep / manage npm version as part of this action).
From a maintainer perspective, pushing out Node releases with fixed NPM versions makes sense. However, as a developer using this action every day I don't think "add a one-liner to fix this" addresses this. Surely the point of this repository is to manage config & prepare the GitHub Action runtime to run a Node project - thus adding a NPM version config is the solution to this? Especially if this action can then cache this NPM version for future runs, in a similar fashion to caching Node versions.
If no support for npm-version
is coming, at least add another link under Advanced Usage to cover this topic?
With the most recent addition of setting up caching automatically in setup-node
I'm rethinking my position of managing npm, especially since the cache should be variable to the version of npm
This is tripping me up in https://github.com/avajs/ava/pull/2867 βΒ that PR introduces an .npmrc
value that is only recognized in the latest npm@8.1.2
. It'd be great if I could enforce that version through the action configuration, especially since it seems to trip up over the warnings. However that probably counts as a separate bug, see https://github.com/actions/setup-node/issues/352.
Updating npm
after setting up the node triggers following error:
Hello @char0n. You get an error because I can suppose you use setup-node without specifying node-version. In that case the action will use default node installed on the hosted images. For Linux node is installed with sudo permissions, that is why you have an issue with updating through this command npm install -g npm@latest
.
You can try to use node from the toolcache for that you need to specify node-version input with required version. You can also refer to this comment
Hi @dmitry-shibanov,
I was using explicit node version, so what you describing probably doesn't apply to me.
- name: Setup node
uses: actions/setup-node@v2
with:
node-version: ${{ matrix.node }}
I could find a workaround around this by installing packages with Node.js version that comes with npm@7 and then switching to different Node.js version that actually runs my code: https://github.com/char0n/ramda-adjunct/blob/master/.github/workflows/nodejs.yaml#L54
I hope to soon see an option to pass npm-version: latest
to address this and avoid having to add extra steps to our already complex pipelines. An option like this makes sense, especially as npm is included with node but can be safely upgraded without breaking node. Some recent changes to npm makes the need to upgrade it.... quite likely.
With the most recent addition of setting up caching automatically in setup-node I'm rethinking my position of managing npm, especially since the cache should be variable to the version of npm
We've recently hit this issue. The npm i -g npm@8
run on one major branch/pr was being picked up by subsequent runs of unrelated branches expecting npm@6
due to the cache, so definitely some stateful leakage across runs. While I understand why, it was bit of a tripping hazard. We will likely roll out npm i -g npm@x
across all workflows and all branches as an extra guard layer, but including npm_version at least as a cache-key bust would be a nice value add. Now to see if we have the time/resources to contribute π€
thanks @fcastilloec
as the time writing this. using ubuntu-latest
to update npm to latest, require to update without sudo and calling it after setting up node actions/setup-node@v2
. the full sample script is like so
install_dependencies:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: actions/setup-node@v2
with:
node-version: 14.x
- name: cache node_modules
uses: actions/cache@v2
with:
key: ${{ runner.os }}-${{ hashFiles('**/package-lock.json') }}
path: |
node_modules
- name: install latest npm
run: |
npm install -g npm &&
npm --version &&
npm list -g --depth 0
- name: install dependencies
run: |
npm ci
output
Run npm install -g npm &&
npm install -g npm &&
npm --version &&
npm list -g --depth 0
shell: /bin/bash -e {0}
/Users/runner/hostedtoolcache/node/14.18.3/x64/bin/npm -> /Users/runner/hostedtoolcache/node/14.18.3/x64/lib/node_modules/npm/bin/npm-cli.js
/Users/runner/hostedtoolcache/node/14.18.3/x64/bin/npx -> /Users/runner/hostedtoolcache/node/14.18.3/x64/lib/node_modules/npm/bin/npx-cli.js
+ npm@8.3.2
added 67 packages from 17 contributors, removed 290 packages and updated 147 packages in 11.682s
8.3.2
/Users/runner/hostedtoolcache/node/14.18.3/x64/lib
βββ npm@8.3.2
I'm also noticing that potentially our npm install
s in CI are passing but in local checkouts failing due to differences in peerDep algorithms between npm 8 and prior versions which shipped with LTS versions of node. I'd definitely be in favour of a npm_version: latest | bundled
which if latest
does an npm install -g npm@latest
or similar.
Can this issue be renamed to drop the mention of npm 7
specifically? Otherwise it looks outdated at a first look since we're on npm 10 now.
@fregante Done
Note that Node is considering removing npm and having corepack install it, which would make this unnecessary if corepack was implemented.
Is there a way to setup the action to use npm 7?
What about
npm_version: 7
like actually it's done fornode_version
?