No. A lockfile in your component library does not reach the apps that install it. The npm documentation says package-lock.json cannot be published and is ignored anywhere other than the root project. Each consuming app resolves your dependency ranges on its own, using its own lockfile.
What the lockfile does protect
The lockfile in your library repo pins what your own CI, Storybook and tests install. That matters: it makes your visual tests repeatable and your builds comparable from one day to the next. It does not describe what ships to your users.
For the consuming app, the library arrives as a package with a list of ranges. The app's installer picks versions that satisfy them, within whatever its own lockfile already holds. Two apps using the same library release can therefore run different versions of the library's dependencies.
Why it surprises teams
Design system owners often scan their repo, see a clean result, and assume the apps are clean too. The scan is true for the repo lockfile and silent about the app trees. A vulnerable version inside a range can still be selected by an app that never refreshed its lockfile.
| Question | Library lockfile answers it? |
|---|---|
| What does our CI install? | Yes |
| What does app A install after adding the library? | No, only app A's lockfile does |
| Did a new advisory hit a range we declare? | Only by checking the range against advisories |
Your options, from light to heavy
- Tighten ranges for dependencies that carry weight. If your library uses a utility that has had security fixes, set the lower bound at the patched release so no app can resolve below it.
- Keep runtime dependencies few. Every runtime dependency of a UI library is inherited by every app. Move build time tools to dev dependencies.
- Check consumer trees, not just your repo. Scan each app's lockfile and look for the versions of your dependencies that actually resolved.
- Consider a shrinkwrap file only with care. The same npm page notes that a shrinkwrap file can be published and dictates resolutions, but it removes the app's ability to pick a newer patched version on its own. It is rarely right for a UI library.
- Publish an advisory note. When a dependency fix matters, say so in your changelog and tell app teams which range floor to adopt.
The related question of whether an app can override your dependency is covered in npm overrides: how to pin a transitive dependency. The short version is that overrides belong to the root project, so the app decides.
A simple routine
Once a month, pick the three most used apps. For each, list the resolved versions of your library's runtime dependencies and compare them with your declared floors. If an app sits below a patched version, the cause is nearly always a stale lockfile, and the fix is a routine update pull request.
Safeguard reads lockfiles across repositories and flags vulnerable resolved versions per app, so the comparison does not have to be done by hand. You can run a free scan at gold.safeguard.sh/scan.
Quick check
Does npm ci in the app use my library's lockfile?
No. It uses the app's own lockfile. Your library's lockfile is not part of the published package.
Should I commit a lockfile in the library repo anyway?
Yes. It makes your own builds and tests reproducible, even though it does not travel to consumers.
Sources
- npm documentation: package-lock.json versus npm-shrinkwrap.json
- npm package.json documentation: overrides
Last reviewed: 19 October 2026.
