Skip to content

Commit the lockfile and let a bot bump it

Commit your lockfile, and let an automated bot propose upgrades as reviewable pull requests.

EngineersVibe codersnodepythongogithubdocker

Without a lockfile, two machines running the same command get different code, and 'works on my machine' becomes literally true and impossible to argue with. With a lockfile and no update bot, you get the opposite failure: a frozen dependency graph that quietly accumulates known vulnerabilities until an upgrade becomes a project. You need both halves.

What goes wrong: A build that succeeded yesterday fails today with no commit between, or a two-year-old transitive dependency with a public advisory.

What agents change: Agents add dependencies casually, because adding one is the shortest path to a working answer.

You are violating it when

  • No lockfile is tracked for your package manager.
  • No Dependabot or Renovate configuration exists.
  • Dependency upgrades happen in one large annual batch.

The usual objection: That pinning and updating are opposed. The lockfile is what makes an update reviewable — it is the diff.

A dependency lockfile turns the resolved dependency graph into repository state. The exact versions of direct and transitive packages become part of the reviewable history, not something each machine rediscovers during install. An update bot completes the loop by making dependency movement happen through normal pull requests instead of through occasional local commands or surprise installer behavior.

This works because it separates repeatability from change. The lockfile makes today’s install match yesterday’s install when no dependency commit changed. The bot then creates explicit commits when newer versions are available, so CI, tests, security scanners, and reviewers evaluate the actual graph being proposed. A vulnerable transitive package is no longer hidden inside an installer decision; it appears as a diff that can be merged, delayed, or reverted.

The misconception is that pinning and updating are opposed. They solve different halves of the same problem. Unpinned dependencies create uncontrolled change, while pinned dependencies without automation create stagnation. The lockfile is what makes an update inspectable: it records exactly which packages moved and gives the team a concrete artifact to review.

When an agent is writing code, this matters more. Agents often add a library because it is the quickest route to a compiling answer, and they may not notice the long-term maintenance cost. A committed lockfile exposes the full dependency impact of that choice, and automated update PRs keep that impact visible after the initial feature is done.

Install it

npx klay practices add lockfile-committed
  • .github/dependabot.ymlcreate
    # Klay practice: lockfile-committed
    # https://klaylearn.com/practices/lockfile-committed
    #
    # Keeps the dependency graph pinned AND moving. A lockfile with no update bot
    # is a frozen graph quietly accumulating advisories until upgrading becomes a
    # project rather than a pull request.
    #
    # Everything is GROUPED and weekly on purpose. Ungrouped daily Dependabot is
    # the reason most teams turn Dependabot off: twenty pull requests nobody reads
    # is indistinguishable from no pull requests, except that it is noisier.
    #
    # Delete the ecosystems you do not use — Dependabot warns about directories
    # that do not exist.
    version: 2

The previews are the first lines of each file; the command writes them in full. Existing files are never overwritten.

How you know it stuck

npx klay practices audit reports these checks for this practice:

  • lockfile-committed
  • dependency-updates

Where this comes from

  1. Dependabot version updates - GitHub DocsGitHub Docs · Official docsDefines automated dependency updates as pull requests from the platform many teams already use.
  2. Dependabot version updates are now generally available - GitHub CheckoutGitHub · Official docsGives a short first-party walkthrough of upgrades arriving as ordinary reviewable GitHub pull requests.
  3. ossf/scorecardOpenSSF Scorecard · Engineering blog · 5,631★Turns the practice into measurable repository checks for pinned dependencies and update automation.
  4. renovatebot/renovateRenovate · Community tool · 22,266★Shows the updater half as executable infrastructure across many package ecosystems and lockfile formats.

Questions

The bot opens too many pull requests.
Group them and lower the frequency. A weekly grouped PR is the setting most teams should have started on.