fix(lambda-nodejs): run beforeInstall hook after workspace files are written

[Zelys-DFKH]

Fixes #37898.

Credit to @cmodijk: the issue report traces the execution order exactly, identifies the root cause, and spells out what the fix should look like. This PR implements what you described.

---

The problem

On pnpm v11, strictDepBuilds is the effective default. Any NodejsFunction that bundles nodeModules with a native-build dependency (e.g. ssh2-sftp-client → cpu-features) hits this at deploy time:

ERR_PNPM_INSTALL_SCRIPTS_NOT_ALLOWED  cpu-features@1.x.x is not allowed to run install scripts

The beforeInstall hook was designed to handle this: append allowBuilds entries to pnpm-workspace.yaml before the install runs. It silently doesn't work, which is worse than not existing.

Why

CDK writes an empty pnpm-workspace.yaml to prevent pnpm from walking up to a monorepo root (introduced in #21910, still the right call). The bug was ordering. Before this fix:

beforeBundling → esbuild → [beforeInstall] → write pnpm-workspace.yaml + install → afterBundling
                                ↑ hook fires here        ↑ empty yaml written here

Whatever the user wrote in beforeInstall got overwritten a step later. The hook's name is a lie.

Fix

Splits node-modules file-ops into two phases via a new NodeModuleFileOps interface:

• prepareSteps: writes pnpm-workspace.yaml, package.json, and the lockfile
• installSteps: runs the package manager and post-install cleanup

createBundlingSteps puts beforeInstall between them, for both Docker and local bundling.

beforeBundling → esbuild → write pnpm-workspace.yaml → [beforeInstall] → install → afterBundling
                                        ↑ files written here    ↑ hook fires here

No behavior change for callers where beforeInstall returns [] (the default).

The refactor makes createBundlingSteps slightly more involved. dockerFileOps and localFileOps are both private, so there's no API surface change.

Validation

Unit test (bundling.test.ts): The beforeInstall hook fires after pnpm workspace files are written (Docker) test asserts the Docker shell command orders pnpm-workspace.yaml write → beforeInstall → pnpm install. This is the test that would have caught the bug.

E2E behavioral test (bundling-package-managers-e2e.test.ts): The pnpm-specific / beforeInstall writes to pnpm-workspace.yaml survive CDK workspace setup test runs CDK synthesis with a minimal pnpm project (local and Docker where available), writes allowBuilds: to pnpm-workspace.yaml in beforeInstall, reads the output file, and checks the content survived. Skipped when pnpm is unavailable locally and Docker bundling is off.

Checklist

• My code adheres to the CONTRIBUTING GUIDE and DESIGN GUIDELINES

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

[aws-cdk-automation]

(This review is outdated)

✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.

[aws-cdk-automation]

This PR cannot be merged because it has conflicts. Please resolve them. The PR will be considered stale and closed if it remains in an unmergeable state.

[aws-cdk-automation]

The pull request linter fails with the following errors:

❌ Fixes must contain a change to an integration test file and the resulting snapshot.

If you believe this pull request should receive an exemption, please comment and provide a justification. A comment requesting an exemption should contain the text Exemption Request. Additionally, if clarification is needed, add Clarification Request to a comment.

✅ A exemption request has been requested. Please wait for a maintainer's review.

[Zelys-DFKH]

Exemption Request

This fix reorders internal bundling steps: it splits fileOps() into prepareSteps / installSteps so beforeInstall fires after workspace files are written. Synthesis produces an identical CloudFormation template — no L1/L2 resource changes. Snapshots capture the output template, not hook execution order; they wouldn't show whether the hook ran before or after the package.json write. The existing unit tests (test_bundling.ts) cover this.

[Zelys-DFKH]

Thanks for writing this up, @marco2216. The trustLockfile detail is a useful one.

Your case is the same write this PR reorders, just surfacing as slowness rather than a failure. The blank pnpm-workspace.yaml drops your settings, so pnpm re-verifies the whole copied lockfile with live registry lookups every time the bundle cache misses. Nothing errors. You just wait.

It also sharpens the pending exemption question, since a template snapshot can't see your symptom either. Synthesis output is byte-identical either way. The only thing that changes is when the hook runs relative to the file write.

Three reports now (@cmodijk, @pivstone, @marco2216), three symptoms, one ordering bug. Branch is updated against main.