Dependency Locking: How OpenClaw Reviews and Packages Dependencies
This page explains how OpenClaw uses pnpm-lock.yaml for dependency review and why npm locks are not committed. It covers published plugin package behavior and native-heavy plugin exceptions.
Read this when
- You are reviewing dependency changes or supply-chain risk
- You are validating root or plugin npm packages before publishing
- You want to understand bundled plugin dependencies
OpenClaw uses pnpm-lock.yaml as its committed boundary for product dependency review. It captures the resolved dependency graph used by source checkouts and CI, ensuring transitive changes remain visible during code review.
OpenClaw does not commit npm-format locks for product packages or include them in package tarballs. npm 12 removed shrinkwrap support, which includes the npm shrinkwrap command and loading npm-shrinkwrap.json from package roots or dependency tarballs.
The trusted ClawHub release toolchain is a separate exception: .github/release/clawhub-cli/package-lock.json is a committed npm 12 project lock used by release automation. It is not shipped inside an OpenClaw package.
Published package behavior
Published OpenClaw plugin packages bundle their runtime dependency files in the tarball by default. Those files ship with the plugin and behave identically whether the operator uses npm, pnpm, or Bun.
Native-heavy plugins opt out of runtime dependency bundling because their dependency trees contain platform-specific or large native artifacts. Those plugins resolve dependencies at install time from exact-pinned direct dependencies. The root openclaw package also resolves dependencies at install time and does not bundle its full dependency tree.
Neither path publishes a lockfile:
- root and plugin tarballs contain neither
npm-shrinkwrap.jsonnorpackage-lock.json; pnpm-lock.yamlremains the reviewed source dependency graph;- npm package locks exist only transiently while OpenClaw validates package graphs or runs
npm cito assemble a bundled plugin.
Validate npm dependency graphs
The npm-lock checker generates package-lock.json in a temporary directory, applies workspace overrides, and rejects any generated registry version absent from pnpm-lock.yaml. It does not write a lockfile into the checkout.
# Root and every publishable package
pnpm deps:npm-lock:check
# Only packages affected by the current changeset
pnpm deps:npm-lock:check:changed
Inspect a plugin tarball
npm pack @openclaw/discord@<version> --json --pack-destination /tmp/openclaw-plugin-pack
tar -tf /tmp/openclaw-plugin-pack/openclaw-discord-<version>.tgz | grep '^package/node_modules/'
tar -tf /tmp/openclaw-plugin-pack/openclaw-discord-<version>.tgz | grep -E '^package/(npm-shrinkwrap|package-lock)\.json$' && exit 1 || true
The node_modules entries prove that the plugin carries its bundled runtime payload. The final check proves that neither npm lockfile format ships in the tarball.