Broken generated pnpm lock file (ERR_PNPM_ERR_PNPM_LOCKFILE_MISSING_DEPENDENCY)

[diginikkari]

Current Behavior

I'm using @nx/webpack:webpack executor with "generatePackageJson": true.

When I'm building production build of app and deploying it I'm getting following error:

Lockfile is up to date, resolution step is skipped
 WARN  Broken lockfile: no entry for '/strip-ansi/6.0.1' in pnpm-lock.yaml
 ERR_PNPM_ERR_PNPM_LOCKFILE_MISSING_DEPENDENCY  The lockfile is broken! Resolution step will be performed to fix it.

Expected Behavior

lock file shoud be correct and there should be no error.

GitHub Repo

https://github.com/diginikkari/nx-next

Steps to Reproduce

1. add app with webpack plugin pnpm nx g @nx/react:app my-app --bundler=webpack
2. enable 'generatePackageJson' in ´project.json´
3. install glob as dev dependency pnpm install -d [email protected] (this will add [email protected] dependency)
4. install msw as dependency pnpm install msw (this will add [email protected] dependency)
5. add import { rest } from 'msw'; to app to include msw as dependency for app
6. build app pnpm nx run my-app:build:production
7. copy generated dist folder to outside of workspace and run 'pnpm install' inside it.

Nx Report

Node   : 20.2.0
   OS     : darwin-arm64
   pnpm   : 8.6.1
   
   nx                 : 16.4.0-beta.2
   @nx/js             : 16.4.0-beta.2
   @nx/jest           : 16.4.0-beta.2
   @nx/linter         : 16.4.0-beta.2
   @nx/workspace      : 16.4.0-beta.2
   @nx/cypress        : 16.4.0-beta.2
   @nx/devkit         : 16.4.0-beta.2
   @nx/esbuild        : 16.4.0-beta.2
   @nx/eslint-plugin  : 16.4.0-beta.2
   @nx/next           : 16.4.0-beta.2
   @nx/node           : 16.4.0-beta.2
   @nx/react          : 16.4.0-beta.2
   @nx/storybook      : 16.4.0-beta.2
   @nrwl/tao          : 16.4.0-beta.2
   @nx/vite           : 16.4.0-beta.2
   @nx/web            : 16.4.0-beta.2
   @nx/webpack        : 16.4.0-beta.2
   nx-cloud           : 16.0.5
   typescript         : 5.1.3
   ---------------------------------------
   Community plugins:
   @mands/nx-playwright : 0.6.2
   ---------------------------------------

Failure Logs

No response

Operating System

• macOS
• Linux
• Windows
• Other (Please specify)

Additional Information

I tried it with 16.3.2 and with latest beta 16.4.0-beta.2.

Lockfile generation seems to select /[email protected] entry into the generated lock file even though there is only string-width: 4.2.3 dependency in app's dependencies.

[diginikkari]

I found a workaround by adding manual step to run pnpm install --fix-lockfile --lockfile-only in dist folder after build.

[halfbakedsneed]

I've just experienced this same issue with set of different private packages. I think the issue has to do with the fact that the same dependency (in OP's case [email protected]) appears multiple times in the dependency tree, with certain instances being aliased.

Dependency Tree:

NOTE: This is not the entire dependency tree, I have trimmed it for the sake of brevity.

glob 10.2.6
└─┬ jackspeak 2.2.1
  └─┬ @isaacs/cliui 8.0.2
    └── strip-ansi 6.0.1 // aliased as `strip-ansi-cjs`
msw 1.2.2
└─┬ inquirer 8.2.5
  └── strip-ansi 6.0.1 // not aliased

During initial graph construction (pre-pruning), the package name selected for the node with the key /strip-ansi/6.0.1 is the aliased package name, strip-ansi-cjs, not strip-ansi (this happens here: findPackageName). This appears to be problematic, as only msw is imported within the nx project being built. This means the pruning process will simply omit the strip-ansi-cjs node from the resulting lock file.

If I patch findPackageName to simply always return the root part of the key (i.e /<this part>/x.y.z) instead of searching the snapshots for a package name, it resolves this particular issue. However, I suspect this is a poor long-term fix and may cause other issues.

[meeroslav]

@halfbakedsneed can you please open a new issue, as these two issues are not related. Please link it to this one so that we can easily track it.

Actually they might be related after all.

[meeroslav]

@diginikkari, this is an interesting issue. Thank you for the reproduction, I will have to dig deeper to see why the dependencies are not correct.

[github-actions]

This issue has been closed for more than 30 days. If this issue is still occuring, please open a new issue with more recent context.