fix(lambda-nodejs): direct esbuild is slower than necessary#37380
Open
fix(lambda-nodejs): direct esbuild is slower than necessary#37380
Conversation
If `esbuild` is available as a dependency in the current project (so we can skip Docker runs), then `esbuild` is still being executed via `npx` or `yarn run`. The overhead of these can be quite large for many small commands! - `npx`; adds ~400ms - `yarn run` (in the case of Yarn Classic); adds ~150ms In both NPM and Yarn Classic's case, we can also run the command directly as `node_modules/.bin/esbuild`, which adds only a few milliseconds! So we fall back to that solution. There are still a couple of suboptimal things here that I'm not addressing yet because I don't know how: - `esbuild` is by default a dispatcher script that will execute the right binary for the current platform. A `postinstall` script normally swaps out the dispatcher script for the actual binary so that dispatch can be skipped, but if it isn't skipped that adds another 100-150ms. - Yarn doesn't seem to execute the `postinstall`, or the `postinstall` doesn't work in a Yarn environment, meaning that Yarn users pay an unskippable dispatching penalty. - Yarn Berry (the modern Yarn) even makes it impossible to run `esbuild` without going through `yarn` itself, adding *another* unskippable 100-150ms for every invocation. All this means that the fastest local bundling experience will be on (*gulp*) `npm`...
rix0rrr
changed the title
aws-cdk-automation
previously requested changes
Mar 27, 2026
rix0rrr
added
pr-linter/exempt-test
aws-cdk-automation
dismissed
their stale review
✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.
aws-cdk-automation
added
the
pr/needs-maintainer-review
aws-cdk-automation
temporarily deployed
to
automation
GitHub Actions
Inactive
aws-cdk-automation
temporarily deployed
to
automation
GitHub Actions
Inactive
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
If
esbuildis available as a dependency in the current project (so we can skip Docker runs), thenesbuildis still being executed vianpxoryarn run. The overhead of these can still be quite large if there are many bundles to produce in the course of a CDK application!npx; adds ~400msyarn run(in the case of Yarn Classic); adds ~150ms (but see the remarks about the dispatcher below)In both NPM and Yarn Classic's case, we can also run the command directly as
node_modules/.bin/esbuild, which adds only a few milliseconds! So we fall back to that solution.There are still a couple of suboptimal things here that I'm not addressing yet because I don't know how:
esbuildis by default a dispatcher script that will execute the right binary for the current platform. Apostinstallscript normally swaps out the dispatcher script for the actual binary so that dispatch can be skipped, but if it isn't skipped that adds another 100-150ms.postinstall, or thepostinstalldoesn't work in a Yarn environment, meaning that Yarn users always pay the dispatching penalty.esbuildwithout going throughyarnitself, adding another unskippable 100-150ms for every invocation.All this means that the fastest local bundling experience will be on (gulp)
npm...(This PR also moves private source files in
aws-lambda-nodejsinto aprivatedirectory, so that it's very clear what parts of the module are free to play with and which ones have backwards compatibility requirements on their API)By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license