Allow to set a custom npm version with `npm_version` option

[robertsLando]

Is there a way to setup the action to use npm 7?

What about npm_version: 7 like actually it's done for node_version?

[maxim-lobanov]

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

[robertsLando]

@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

[smorimoto]

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.

[mendrik]

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

[dmitry-shibanov]

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

[Fryuni]

It seems setting node-version: 15 now gets a release with the proper fix. It is working without having to update npm

[vinayakkulkarni]

Just like we have an option to use node versions, we should also have an option to choose npm versions

[fcastilloec]

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...

[smorimoto]

What about doing with sudo?

[fcastilloec]

@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 + [email protected]
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

[smorimoto]

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.

[smorimoto]

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.

[stereobooster]

Run npm install -g [email protected]
npm ERR! code E404
npm ERR! 404 Not Found - GET https://npm-proxy.fury.io/***/***/npm - bad_request
npm ERR! 404 
npm ERR! 404  '[email protected]' is not in the npm registry.

Solution

    - name: npm 7
      run: npm i -g npm@7 --registry=https://registry.npmjs.org

[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).

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

[jimmed]

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

Example of caching node_modules across jobs with npm v7

name: CI
concurrency:
  group: ${{ github.ref }}
  cancel-in-progress: true
on:
  - pull_request
jobs:
  configure-workspace:
    name: Configure workspace
    runs-on: ubuntu-latest
    steps:
      - name: Checkout branch
        uses: actions/checkout@v2
        with:
          ref: ${{ github.event.pull_request.head.ref }}
      - name: Setup node.js
        uses: actions/setup-node@v2
        with:
          node-version: '14'
      - name: Cache dependencies
        uses: actions/cache@v2
        id: node-cache
        with:
          path: node_modules
          key: node-14-ubuntu-latest-${{ hashFiles('package-lock.json') }}
      - name: Install dependencies
        if: steps.cache.outputs.cache-hit != 'true'
        run: npx npm@7 clean-install
  unit-tests:
    name: Unit tests
    needs:
      - configure-workspace
    runs-on: ubuntu-latest
    steps:
      - name: Checkout branch
        uses: actions/checkout@v2
        with:
          ref: ${{ github.event.pull_request.head.ref }}
      - name: Setup node.js
        uses: actions/setup-node@v2
        with:
          node-version: '14'
      - name: Cache dependencies
        uses: actions/cache@v2
        id: node-cache
        with:
          path: node_modules
          key: node-14-ubuntu-latest-${{ hashFiles('package-lock.json') }}
      - name: Run unit tests
        run: npm test

[bingettinit97]

run: npx npm@7 i

[MylesBorins]

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

[vinayakkulkarni]

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

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

[pzuraq]

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

[mfbx9da4]

the issue with

run: npm i -g npm@7

is that npm itself won't be in the cache 😢

[jdrydn]

@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?

[MylesBorins]

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

[novemberborn]

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 [email protected]. 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.

[char0n]

Updating npm after setting up the node triggers following error:

[dmitry-shibanov]

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

[char0n]

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

[ssbarnea]

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.

[dcousineau-godaddy]

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 🤔

[abdulghani]

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
+ [email protected]
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
└── [email protected]

[ThisIsMissEm]

I'm also noticing that potentially our npm installs 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.