search

floydspace / serverless-esbuild

💨 A Serverless framework plugin to bundle JavaScript and TypeScript with extremely fast esbuild
MIT License
445 stars 137 forks source link

Pnpm prune fails with overrides #551

Open loganyott opened 1 month ago

loganyott commented 1 month ago

Describe the bug When using overrides in a pnpm monorepo, packaging will always break on the prune step due to the overrides not being included.

To Reproduce https://github.com/loganyott/serverless-esbuild-pnpm-prune-example In the repo, run

  1. pnpm install
  2. cd package-one
  3. CI=true pnpm build

For any other repo,

  1. Add a package to a pnpm monorepo
  2. Add an overrides definition to the root of the workspace. Pnpm requires this to be defined at the root level
  3. Use packager: pnpm and mark a dependency as external
  4. Run sls package in the package. This works
  5. Run CI=true sls package in the package. You will get  ERR_PNPM_LOCKFILE_CONFIG_MISMATCH  Cannot proceed with the frozen installation. The current "overrides" configuration doesn't match the value found in the lockfile. This appears to be due to pnpm prune enforcing --frozen-lockfile in a CI environment

Expected behavior CI=true sls package executes successfully

Screenshots or Logs If applicable, add screenshots or logs to help explain your problem.

Versions (please complete the following information):

Additional context During some debugging, I found that the pnpm install step with the copied dependencies works, as that manually passes in --no-frozen-lockfile. This fails on the pnpm prune step. prune does not appear to support a --no-frozen-lockfile step. I don't exactly understand what pnpm prune is accomplishing in this case either as we are only copying over production dependencies from the package.json file. Do we see an issue with either not calling prune or using the ignoreLockfile argument added for yarn and using that to conditionally not run prune for pnpm?

Alternatively, we could update the pnpm packager to copy over the pnpm.overrides configuration from the root package.json? This might be more correct as the overrides definition can change the resolved versions of modules that are installed.