Skip to content
Laksana Adi

Why package-lock.json Belongs in Your Automation Repository

In automation projects, I’ve often seen package-lock.json treated like clutter. It can be large, hard to read, and a source of merge conflicts. So someone adds it to .gitignore and moves on. From my perspective in QA, that small decision can create much bigger problems later.

Reproducible Tests Matter

One of the most frustrating things in testing is when a test passes today and fails tomorrow, even though nobody has changed the code. Sometimes, the problem isn’t the application at all; instead, it’s a dependency that has changed.

Without a lockfile, running npm install on two different machines can install different versions of Playwright, dotenv, or other libraries. That’s because package.json can specify a version range, such as ^1.50.0, rather than one exact version.

When that happens, we waste time investigating failures that aren’t caused by a product bug or a test bug, but by differences in our environments. We’ve all heard some version of, “It works on my machine.” Committing the lockfile helps everyone on the team, as well as every CI pipeline, install the same dependency versions. When a test fails, I can spend more time looking for the real cause instead of chasing environment differences.

A Small Process Decision That Reduces Risk

From a QA lead’s perspective, committing the lockfile is a low-cost way to make the process more predictable.

It helps keep local development environments and CI consistent. When a new team member joins, they can run npm ci and install the versions recorded in the lockfile, rather than spending time figuring out why their setup behaves differently.

It also makes upgrades more deliberate. Dependency changes can be introduced through a pull request, reviewed, and rolled back if necessary, rather than slipping in unnoticed when someone installs packages.

There’s a security angle, too. Automation repositories may use credentials stored in .env, such as test-account logins or database access details. Supply-chain attacks can target npm dependencies, so unexpected package changes deserve attention. A lockfile helps prevent dependency versions from shifting silently, but it isn’t a complete security solution on its own. I still review lockfile changes in pull requests, especially when dozens of packages change without a clear reason.

The Habits I Try to Follow

I keep a few simple rules in mind:

  1. Commit package-lock.json alongside package.json whenever dependencies are added or changed.
  2. Use npm ci in CI rather than npm install. It installs from the lockfile and fails when the lockfile and package.json are out of sync.
  3. Don’t commit node_modules/ or .env.
  4. Stick to one package manager per repository so the team has a consistent source of truth.

These habits don’t eliminate every dependency problem, but they make the environment easier to reproduce and changes easier to review.

I’ve come to see package-lock.json as more than a generated file that happens to live in the repository. For me, it’s part of the test setup: a small, practical way to reduce surprises and make failures easier to understand. When people rely on QA results to make release decisions, being able to reproduce those results isn’t a luxury; rather, it’s part of doing the job well.