@nx/esbuild:esbuild with thirdParty: false regression from 18.3.4 to 19.0.x with pnpm

[atsjo]

Current Behavior

@nx/esbuild:esbuild with thirdParty: false and generatePackageJson: true removes to much while filtering pnpm-lock.yaml, so pnpm install fails when using the lock file.
pnpm-lock.nx-19.0.1.txt

Expected Behavior

pnpm install works with filtered lock file, as for 18.3.4
pnpm-lock.nx-18.3.4.txt

GitHub Repo

No response

Steps to Reproduce

1. use esbuild to bundle with thirdParty: false and generatePackageJson: true with nx 18.3.4
2. use esbuild to bundle with thirdParty: false and generatePackageJson: true with nx 19.0.1
3. observe difference in generated pnpm-lock.yaml

Nx Report

Node   : 20.12.2
OS     : win32-x64
pnpm   : 8.15.8

nx                 : 19.0.1
@nx/js             : 19.0.1
@nx/jest           : 19.0.1
@nx/linter         : 19.0.1
@nx/eslint         : 19.0.1
@nx/workspace      : 19.0.1
@nx/angular        : 19.0.1
@nx/devkit         : 19.0.1
@nx/esbuild        : 19.0.1
@nx/eslint-plugin  : 19.0.1
@nrwl/tao          : 19.0.1
@nx/web            : 19.0.1
@nx/webpack        : 19.0.1
typescript         : 5.4.5
---------------------------------------
Registered Plugins:
@nx/eslint/plugin
@nx/jest/plugin
---------------------------------------
Community plugins:
angular-calendar : 0.31.1

Failure Logs

ERR_PNPM_LOCKFILE_MISSING_DEPENDENCY  Broken lockfile: no entry for '[email protected]' in pnpm-lock.yaml

Below is items removed from working pnpm-lock.yaml for 18.3.4 attached above:

  /[email protected]:
    resolution: {integrity: sha512-quJQXlTSUGL2LH9SUXo8VwsY4soanhgo6LNSm84E1LBcE8s3O0wpdiRzyR9z/ZZJMlMWv37qOOb9pdJlMUEKFQ==}
    engines: {node: '>=8'}
    dev: false

  /[email protected]:
    resolution: {integrity: sha512-zbB9rCJAT1rbjiVDb2hqKFHNYLxgtk8NURxZ3IZwD3F6NtxbXZQCnnSi1Lkx+IDohdPlFp222wVALIheZJQSEg==}
    engines: {node: '>=8'}
    dependencies:
      color-convert: 2.0.1
    dev: false

  /[email protected]:
    resolution: {integrity: sha512-RRECPsj7iu/xb5oKYcsFHSppFNnsj/52OVTRKb4zP5onXwVF3zVmmToNcOfGC+CRDpfK/U584fMg38ZHCaElKQ==}
    engines: {node: '>=7.0.0'}
    dependencies:
      color-name: 1.1.4
    dev: false

  /[email protected]:
    resolution: {integrity: sha512-dOy+3AuW3a2wNbZHIuMZpTcgjGuLU/uBL/ubcZF9OXbDo8ff4O8yVp5Bf0efS8uEoYo5q4Fx7dY9OgQGXgAsQA==}
    dev: false

  /[email protected]:
    resolution: {integrity: sha512-MSjYzcWNOA0ewAHpz0MxpYFvwg6yjy1NG3xteoqz644VCo/RPgnr1/GGt+ic3iJTzQ8Eu3TdM14SawnVUmGE6A==}
    dev: false

  /[email protected]:
    resolution: {integrity: sha512-zymm5+u+sCsSWyD9qNaejV3DFvhCKclKdizYaJUuHA83RLjb7nSuGnddCHGv0hk+KY7BMAlsWeK4Ueg6EV6XQg==}
    engines: {node: '>=8'}
    dev: false

Package Manager Version

No response

Operating System

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

Additional Information

No response

[atsjo]

Same for 19.0.2

[atsjo]

I have tracked down when this regression was introduced, and it was from 19.0.0-beta.6 to beta.7 with commit #23017. So this only affects pnpm, and was included in a performance pr originating from @JamesHenry. My workaround is to downgrade the nx package to 18.3.4 or 19.0.0-beta.6, or else I cant deploy my firebase functions, since pnpm install fails during deploy...

[wewelll]

same issue here

[meeroslav]

Thank you @atsjo, for reporting this issue.

Can you please create a minimal repo or at least paste here the contents of the root pnpm-lock.yaml. We can use this then to see what is being filtered out.

This issue might be fixed with #22906

[atsjo]

here are the root lock-file and the filtered package.json and lock-file:
filtered-package.json.txt
filtered-pnpm-lock.yaml.txt
root-pnpm-lock.yaml.txt

[atsjo]

the fix for this corrected the missing deps, but introduced a new problem with overrides (as reported in issue #26379)... Now it fails with a new error code:

ERR_PNPM_LOCKFILE_CONFIG_MISMATCH  Cannot proceed with the frozen installation. The current "overrides" configuration doesn't match the value found in the lockfile

[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.