Where does this file go?

Save it as .github/workflows/ci.yml in the root of your repository. GitHub automatically detects any YAML file under .github/workflows and runs it on the events you configure, here push and pull_request to your chosen branch.

What does the version matrix do?

The matrix runs the whole job once per Node version you list, in parallel. It catches problems that only appear on a specific runtime, which is important for libraries that must support several Node releases. With fail-fast set to false, one failing version does not cancel the others.

How does dependency caching work?

The setup-node action with the cache option keys a cache off your lockfile. On later runs it restores node_modules' download cache, so npm ci or the equivalent reinstalls from cache instead of hitting the registry, cutting minutes off the job.

Why npm ci instead of npm install?

npm ci installs exactly what is in package-lock.json, fails if the lockfile and package.json disagree, and is faster and more reproducible than npm install. The yarn and pnpm equivalents use --frozen-lockfile for the same guarantee.

Do I need a lint or build script defined?

Yes. The lint step runs your project's lint script and the build step runs your build script, so those names must exist in package.json. If a project has no build step, untick build so the workflow does not fail on a missing script.

GitHub Actions CI Workflow Builder (Node.js)

Email me this result

Get this tool's output sent to your inbox, plus one useful tool a week. No spam, unsubscribe any time.

A GitHub Actions CI workflow builder for Node.js that generates a valid .github/workflows/ci.yml. Pick the Node versions to test, your package manager, and which jobs to run, and it produces a workflow with a version matrix, dependency caching, and lint, test, and build steps.

How it works

The workflow triggers on push and pull_request to the branch you choose. It defines a single build job on ubuntu-latest with a strategy.matrix.node-version listing your versions, so the job runs once per version in parallel. fail-fast: false keeps the other versions running even if one fails, so you see every failure at once.

Each run checks out the code, sets up Node with actions/setup-node@v4 (which keys the dependency cache off your lockfile via cache: npm|yarn|pnpm), installs with the reproducible command for your package manager (npm ci, yarn install --frozen-lockfile, or pnpm install --frozen-lockfile), then runs the lint, test, and build scripts you enabled. For pnpm it also adds the pnpm/action-setup step that the cache wiring requires.

Tips and notes

The script names (lint, test, build) must exist in your package.json. Untick any step whose script you do not have, or the job will fail on a missing script.
The matrix is cheap — testing on the oldest and newest Node versions you support (for example 18 and 22) catches most compatibility issues without burning extra minutes.
For pnpm, the workflow pins pnpm/action-setup@v4 with a version; bump it to match the packageManager field in your package.json if you have one.
To publish or deploy on success, add a second job with needs: build so it only runs after the matrix passes.