esbuild binary path is not correctly detected in 3.6.0 and 3.7.0 when using Yarn 2 Plug&Play

[matthias-pichler]

Describe the bug

We have a cdk application that uses Yarn 2 Plug and Play. We use this package to leverage the esbuild-plugin-pnp as described in your examples.

When we upgrade to 3.6.0 or 3.7.0 cdk synth fails with

Bundling asset end-user-iam-dev-feature-ceg-m-ikccks/UserPool/CognitoLambdas/PostConfirmation/TypeScriptCode/Stage...
Error: The service was stopped: spawn undefined ENOENT
    at /builds/warrify/services/end-user-iam/.yarn/unplugged/esbuild-npm-0.14.49-8ea32c7f59/node_modules/esbuild/lib/main.js:1337:25
    at /builds/warrify/services/end-user-iam/.yarn/unplugged/esbuild-npm-0.14.49-8ea32c7f59/node_modules/esbuild/lib/main.js:666:9
    at ChildProcess.afterClose (/builds/warrify/services/end-user-iam/.yarn/unplugged/esbuild-npm-0.14.49-8ea32c7f59/node_modules/esbuild/lib/main.js:644:7)
    at ChildProcess.emit (node:events:527:28)
    at Process.ChildProcess._handle.onexit (node:internal/child_process:289:12)
    at onErrorNT (node:internal/child_process:478:16)
    at processTicksAndRejections (node:internal/process/task_queues:83:21)
node:internal/process/esm_loader:94
    internalBinding('errors').triggerUncaughtException(
                              ^
Error: The service was stopped: spawn undefined ENOENT
    at /builds/warrify/services/end-user-iam/.yarn/unplugged/esbuild-npm-0.14.49-8ea32c7f59/node_modules/esbuild/lib/main.js:13[37](https://gitlab.com/warrify/services/end-user-iam/-/jobs/2709204974#L37):25
    at /builds/warrify/services/end-user-iam/.yarn/unplugged/esbuild-npm-0.14.49-8ea32c7f59/node_modules/esbuild/lib/main.js:666:9
    at ChildProcess.afterClose (/builds/warrify/services/end-user-iam/.yarn/unplugged/esbuild-npm-0.14.49-8ea32c7f59/node_modules/esbuild/lib/main.js:644:7)
    at ChildProcess.emit (node:events:527:28)
    at Process.ChildProcess._handle.onexit (node:internal/child_process:289:12)
    at onErrorNT (node:internal/child_process:478:16)
    at processTicksAndRejections (node:internal/process/task_queues:83:21)
/builds/warrify/services/end-user-iam/.yarn/unplugged/aws-cdk-lib-virtual-[47](https://gitlab.com/warrify/services/end-user-iam/-/jobs/2709204974#L47)bf6f84bd/node_modules/aws-cdk-lib/core/lib/asset-staging.js:2

The interesting part being spawn undefined ENOENT

When we explicitly set ESBUILD_BINARY_PATH=/workspace/npm-packages/.yarn/unplugged/esbuild-npm-0.14.49-8ea32c7f59/node_modules/esbuild/lib/pnpapi-esbuild-linux-64-esbuild or ESBUILD_BINARY_PATH=/workspace/npm-packages/.yarn/unplugged/esbuild-linux-64-npm-0.14.49-96241737d6/node_modules/esbuild-linux-64/bin/esbuild then synth succeeds.

To make things even weirder: The first lambda function build succeeds but if you have more than 1 Lambda Function then it starts failing (the stack trace shows that the error comes from esbuild in a function named buildOrServeContinue).

To Reproduce

1. Create a repo using yarn 2 plug&play
2. Create a stack with 2 lambda functions
3. run cdk synth

Expected behavior

The automatic inference of the binary path should continue to work as it did in 3.5.0

Versions:

• CDK: 2.31.1
• Node.js: 16.16.0

Additional context

[matthias-pichler]

I think the bug is here. In the detection if esbuild is running in yarn plug&play it sets ESBUILD_BINARY_PATH itself.

so the flow is:

1. ESBUILD_BINARY_PATH === undefined
2. const originalEsbuildBinaryPath = process.env.ESBUILD_BINARY_PATH; stores it in originalEsbuildBinaryPath
3. esbuild is executed the first time (and succeeds) and thereby sets ESBUILD_BINARY_PATH
4. process.env.ESBUILD_BINARY_PATH = originalEsbuildBinaryPath; is run and overrides the setting again with undefined

[mrgrain]

Oh good catch. And thanks for the fix! 🕺

We probably need to get some yarn tests in there eventually 😅