fix: patch SdkProvider._makeSdk for CDK >= 2.177.0 to support path-style S3 URLs#123
Merged
fix: patch SdkProvider._makeSdk for CDK >= 2.177.0 to support path-style S3 URLs#123
Conversation
…S_S3_FORCE_PATH_STYLE is set Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
skyrpex
reviewed
Mar 30, 2026
Comment on lines
+118
to
+126
| // require("aws-cdk/lib") resolves to legacy-exports.js which re-exports SdkProvider as a thin | ||
| // wrapper with only static methods. The real SdkProvider (with _makeSdk and other instance | ||
| // methods) lives in index.js. Load it directly by resolving the package root and bypassing | ||
| // the exports field. | ||
| const loadRealSdkProvider = () => { | ||
| const cdkRoot = path.dirname(require.resolve("aws-cdk/package.json")); | ||
| const indexLib = require(path.join(cdkRoot, "lib", "index.js")); | ||
| return indexLib.SdkProvider; | ||
| }; |
Contributor
There was a problem hiding this comment.
I wasn't convinced this was going to work with aws-cdk@^2.1114.0 because they removed all exports from the package except for a few, making it illegal to access most of the files and forbidding monkey-patching, BUT turns out that importing a module using an absolute path avoids this restriction. This behavior might be a bug in the node resolution algorithm but if it works temporarily, there's no reason not to accept it.
Just be mindful that this patch could stop working anytime. Any future errors are already swallowed so that's good.
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
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.
Problem
When using
cdklocal deploywith CDK >= 2.177.0 against a remote LocalStack endpoint (e.g.*.sandbox.localstack.cloud), asset publishing fails with TLS errors:The root cause is that CDK 2.177.0 reorganised its package structure —
aws-cdk/libnow resolves tolegacy-exports.js, a thin static wrapper that no longer exposes the realSdkProviderinstance methods (e.g._makeSdk). As a result, the existing patching mechanism incdklocalno longer takes effect, and S3 clients are created withoutforcePathStyle: true.Without path-style URLs, the AWS SDK constructs S3 requests using virtual-hosted-style URLs (e.g.
https://<bucket>.abc.sandbox.localstack.cloud/...). The wildcard TLS certificate for sandbox endpoints only covers one subdomain level, so these requests fail the TLS handshake with an internal alert.Solution
Load the real
SdkProviderby resolving the CDK package root and requiringindex.jsdirectly (bypassing theexportsfield), then patch_makeSdkto injectforcePathStyle: trueinto every SDK instance's config.The patch is applied conditionally — only when one of the following is true:
AWS_S3_FORCE_PATH_STYLEis set — explicit opt-in via env varAWS_ENDPOINT_URLhostname contains.sandbox.— automatic detection for remote LocalStack sandbox endpoints