buf.lock

If your buf.yaml declares any deps, it will be accompanied by a buf.lock file that contains your module's dependency manifest. This manifest represents a single, reproducible build of your module.

You can create or update a buf.lock file for your module by running the buf mod update command. For example, suppose that we have this directory layout and buf.lock content for the buf.build/acme/petapis module:

.
├── acme
│   └── pet
│       └── v1
│           └── pet.proto
├── buf.lock
└── buf.yaml

# Generated by buf. DO NOT EDIT.
version: v1
deps:
  - remote: buf.build
    owner: acme
    repository: paymentapis
    commit: 42abe5cfeb904508839378050d95ab13

deps

Each entry in the buf.lock deps key is a module pin, which uniquely represents a specific snapshot of the given module (buf.build/acme/paymentapis:5173e5cfeb904508839378050d95e1de in this case). With this, the local snapshot of the buf.build/acme/petapis module and all of its dependencies are uniquely represented and reproducible.

Push and update modules

You can then publish and share this particular snapshot with your consumers and/or collaborators by pushing it to the BSR with the command:

$ buf push

With this, modules that depend on buf.build/acme/petapis can run buf mod update and notice a new module pin in their buf.lock! For example, we can update the content found in this module's buf.lock by running this:

# Generated by buf. DO NOT EDIT.
version: v1
deps:
  - remote: buf.build
    owner: acme
    repository: paymentapis
    commit: 5173e5cfeb904508839378050d95e1de

Older versions of buf may include branch, commit, digest, and create_time as a part of the dependencies. Your buf.lock shouldn't include these fields if you've run buf mod update with a newer version of buf.

For more on updating dependencies and pushing modules, see the guide to iterating on Modules.