[sdk/nodejs] Support top-level default exports in ESM #8766
Conversation
This file contains 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
Codecov Report
@@ Coverage Diff @@
## master #8766 +/- ##
==========================================
+ Coverage 59.39% 59.40% +0.01%
==========================================
Files 639 639
Lines 98051 98051
Branches 1386 1386
==========================================
+ Hits 58235 58246 +11
+ Misses 36534 36521 -13
- Partials 3282 3284 +2
Continue to review full report at Codecov.
|
iwahbe
approved these changes
Jan 18, 2022
| @@ -0,0 +1,3 @@ | |||
| // Copyright 2016-2021, Pulumi Corporation. All rights reserved. | |||
|
|
|||
| export default async function() { return {helloWorld: 123} } | |||
There was a problem hiding this comment.
Nit: newline, correct year for copyright
t0yv0
approved these changes
Jan 19, 2022
In #7764 and #8655 we added support for ESM entrypoints. However, ESM "default exports" were handled just as "normal" in Node.js dynamic import of ESM - as a `default` proeprty in the export object. This is not a particularly useful behaviour for Pulumi program entry points, and doesn't quite match some of the special logic we apply to non-object exports in CommonJS modules (invoking exported functions, and then awaiting exports promises). Instead, this change adds support for default exports, treating the default export (if present) as the full returned export value. It is for now an error to have both a default export and named exports, since it is unclear what this should mean. In the future, we could potentially relax this and define how these two sets of exports are merged. This is technically a breaking change from the support added in the recent releases, but only in a narrow case, and in that case the Pulumi stack exports were almost certainly not what the user wanted. Fixes #8725, which includes a motivating example where this is ~necessary.
lukehoban
force-pushed
the
lukehoban/8725
branch
from
fac6e39
to
c4c4c10
Compare
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.
In #7764 and #8655 we added support for ESM entrypoints. However, ESM "default exports" were handled just as "normal" in Node.js dynamic import of ESM - as a
defaultproeprty in the export object.This is not a particularly useful behaviour for Pulumi program entry points, and doesn't quite match some of the special logic we apply to non-object exports in CommonJS modules (invoking exported functions, and then awaiting exports promises).
Instead, this change adds support for default exports, treating the default export (if present) as the full returned export value.
It is for now an error to have both a default export and named exports, since it is unclear what this should mean. In the future, we could potentially relax this and define how these two sets of exports are merged.
This is technically a breaking change from the support added in the recent releases, but only in a narrow case, and in that case the Pulumi stack exports were almost certainly not what the user wanted.
Fixes #8725, which includes a motivating example where this is ~necessary.