-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[sdk/nodejs] Support top-level default exports in ESM #8766
Conversation
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.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@@ -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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: newline, correct year for copyright
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.
fac6e39
to
c4c4c10
Compare
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.