fix(webapp): CloudFront Functions fail - #1906
Merged
cdklabs-automation merged 1 commit intoJul 28, 2026
Merged
Conversation
…iled output contains a CommonJS module prologue
The compiled code of the AddHeadersFunction and BadgeRedirectFunction is
inlined verbatim into AWS::CloudFront::Function resources, but was produced
by plain tsc. Depending on the tsconfig, tsc prepends
`Object.defineProperty(exports, "__esModule", { value: true });` — `exports`
does not exist in the CloudFront Functions runtime, so the function throws
on every invocation and the distribution returns 503 for all requests
(regression introduced by the toolchain changes in #1897, shipped in
v0.4.515).
Bundle both handlers with a dedicated esbuild configuration (esm format,
es5 target, neutral platform, no tree-shaking) modelled after
mrgrain/cdk-esbuild's CloudFront function code bundler, replacing the tsc
output at compile time. The bundling script validates that the output
contains no module system artifacts and a top-level handler declaration.
Add a regression test that executes the shipped bundles in a bare vm
sandbox — like the CloudFront runtime, without exports/module/require —
and invokes the handlers.
Also upgrade both functions to cloudfront-js-2.0.
Fixes the v0.4.515 outage report.
cdklabs-automation
enabled auto-merge
July 28, 2026 16:23
Contributor
Dependency Review✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.Scanned FilesNone |
mrgrain
changed the title
mrgrain
changed the title
ShadowCat567
approved these changes
Jul 28, 2026
cdklabs-automation
deleted the
mrgrain/fix/webapp/cloudfront-function-module-prologue
branch
July 28, 2026 16:51
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
3 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.
Fixes the v0.4.515 issue where requests to a Construct Hub deployment returned HTTP 503 with
x-cache: FunctionExecutionError from cloudfront. The compiled code of theAddHeadersFunction(and theBadgeRedirectFunction) is inlined verbatim intoAWS::CloudFront::Functionresources, but it was produced by plaintsc. After the toolchain restructuring in #1897, the compiler started prepending the CommonJS prologueObject.defineProperty(exports, "__esModule", { value: true });to the output. The CloudFront Functions runtime has no module system and noexportsbinding, so the function threw aReferenceErroron every invocation, taking down the whole distribution.Relying on
tscemit for these files was always fragile, because whether the prologue appears depends on tsconfig details that are unrelated to these files and can change in routine dependency or config upgrades — exactly what happened in #1897. Both handlers are now bundled with a dedicated esbuild configuration (esmformat so no module prologue is emitted,es5target,neutralplatform, tree-shaking disabled so the never-exported handler survives), modelled after the CloudFront function bundler in mrgrain/cdk-esbuild. The bundle step runs at the end ofcompileand replaces thetscoutput inlib/, so the shipped artifact is deterministic regardless of tsconfig changes. The bundling script additionally fails the build if the output contains any module system artifacts or lacks a top-levelfunction handler(...)declaration.To guard against any future regression of this class, a new test loads the shipped bundles into a bare
vmsandbox that — like the CloudFront runtime — provides noexports,module, orrequire, and invokes the handlers to verify their behaviour. This test fails against the v0.4.515 artifact.While touching these functions, both are upgraded from
cloudfront-js-1.0tocloudfront-js-2.0. The 2.0 runtime is backwards compatible for this code, lifts the ES 5.1 restrictions, and the esbuild configuration derives its feature lowering from the target runtime, so future handler code can use modern syntax safely.Tested with
yarn build: all unit tests pass (including the new regression tests), integ snapshots are unchanged, and the jest snapshots were regenerated to reflect the clean function code and new runtime.By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license