correct behavior of combination of npm-shrinkwrap.json in lib, and package-lock=false in app?

Hi.
I’m experiencing unexpected behavior, and I’m wondering if this is a bug or by design.

As the relevant npm docs state, npm-shrinkwrap.json files are published to the registry, and should only be considered for a CLI tools and devDependencies.
I’m working on a package that is indeed a CLI that is defined as a devDependency of the apps that consume it.

My goal is to never break the build of the consuming apps because of updates in transitive dependencies that my tool depends of.
The npm-shrinkwrap.json indeed achieves this goal because it’s published to the registry, and when consuming apps run npm install, the exact versions of the packages that are listed in my published npm-shrinkwrap.json are installed in the nested node_modules directory inside the directory of my tool within the root node_modules directory.

However, this desired behavior breaks if the consuming app has an .npmrc file that defined package-lock=false.
I expect that if the app decides to not use a package-lock.json file that’s their business for the rest of the package that depend on, but since my package did publish an npm-shrinkwrap.json file, I expect that it will always be installed with the specific exact versions defined within.

Steps to reproduce:

  1. create 3 packages: app, tool, and dependency.
  2. make tool depend on dependency
  3. add a npm-shrinkwrap.json to tool with an exact version of dependency defined within
  4. publish tool
  5. make tool a devDependency of app
  6. npm install in app

Expected behavior:
app/nodes_modules/tool/node_modules/dependency should exist and contain the exact version of dependency defined in the npm-shrinkwrap.json of tool

Existing behavior:
app/nodes_modules/tool/node_modules/dependency does not exist.
dependency only exists in the root node_modules folder, and the specific version of dependency is not locked to a specific version.

My questions:
Is this behavior a bug or by design?
If it’s a bug, what should be done so it will be fixed? Is there a workaround to achieve predictably reproducible builds for my tool in another way?
If it’s by design, where is it documented?

Thanks.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.