npm ci fails in GitHub Actions

Question

I am working on a pipeline to install npm packages using GitHub Actions, I am getting this error:

npm ERR! code EUSAGE
npm ERR! 
npm ERR! The `npm ci` command can only install with an existing package-lock.json or
npm ERR! npm-shrinkwrap.json with lockfileVersion >= 1. Run an install with npm@5 or
npm ERR! later to generate a package-lock.json file, then try again.
npm ERR! 
npm ERR! Clean install a project
npm ERR! 
npm ERR! Usage:
npm ERR! npm ci
npm ERR! 
npm ERR! Options:
npm ERR! [--no-audit] [--foreground-scripts] [--ignore-scripts]
npm ERR! [--script-shell <script-shell>]
npm ERR! 
npm ERR! aliases: clean-install, ic, install-clean, isntall-clean
npm ERR! 
npm ERR! Run "npm help ci" for more info

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/runner/.npm/_logs/2022-09-09T06_53_34_562Z-debug-0.log
Error: Process completed with exit code 1.

My pipeline looks like this :

name: Veracode frontend Scan
on:
  workflow_dispatch:
    
jobs:
  veracode:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/setup-node@v3
      with:
        node-version: 16
    - run: npm ci

If anyone can help me out, I am not sure where I am going wrong.

Answer 1

Check first if this is related to actions/setup-node issue 498 or PR 103

The npm-ci command does mention:

The main differences between using npm install and npm ci are:

• The project must have an existing package-lock.json or npm-shrinkwrap.json.
• If dependencies in the package lock do not match those in package.json, npm ci will exit with an error, instead of updating the package lock.
• ...

Make sure:

• your npm project does create a package-lock.json (which it should by default)
• it is not ignored (.gitignore) and is part of your repository codebase.

As noted here:

Running npm install for a CI/CD is fundamentally flawed.
It might be acceptable for running tests, but if you rely on reproducible results, you cannot and must not use npm install.

The problem is that npm install will choose whatever version is the newest and that still matches your semver range specified in package.json.
This often works well for some time, but if you suddenly get burned by a broken dependency introduced through a patch release, you potentially will spend hours trying to figure out which exact version you used before.

Without a package-lock.json you have zero traceability and virtually no chance of reproducing the exact previous build ever again.
Quite frankly, anybody suggested otherwise never had to deal with a broken production build because a fricking dev dependency broke on the CI/CD side.

---

The OP learner confirms in the comments a path issue:

The problem was that I had been running the command in the wrong directory, once I switched that where the package-lock.json was and it was fine.

But the error message becomes:

UPSTREAM ERROR 

Fix the upstream dependency conflict, or retry this command with 
--force, or --legacy-peer-deps to accept an incorrect (and potentially broken) 
dependency resolution

From this answer, a npm ci --force is one way to go forward in that case.