doc: notes for 2018-12-19 #243
Conversation
Co-Authored-By: MylesBorins <[email protected]>
| - Myles: can we agree that we're adding exploring the `export *` space to our roadmap? | ||
| - Guy: I've spent so much time on this. Nobody has wanted to contribute, nor has anyone provided a use-case for `export *` with CJS. I've worked with TC39 to rewrite parts of the spec for transparent interop. And then one person coming to this thread has jumped into the thread and derailed the process. This is incredibly demoralizing. If someone can provide *one* use-case, that would be minimally helpful here; along with someone willing to talk about the minimal details | ||
| - JDD: have tons of users who would be impacted by this; took a survey of code in the wild. | ||
| - Bradley: Actually didn't see that many occurrences; numbers don't entirely back that up. Many of those are occurrences are compiled code anyway. |
There was a problem hiding this comment.
☝️ I was referencing Bradley's data from the PR being discussed. As I understand it, from Bradley's POV there wasn't much use because he doesn't see more full-featured named exports support as a way for folks to drop transpilation in favor of native support. I do, so having higher usage in Babel is a strong indicator of potential use to me. For me, one of the reasons we're even trying to add named exports support is because there is an expectation in the ecosystem today, established by things like Babel.
After the meeting I IM'd with Bradley to better understand his views on interop and module effort goals and outcomes.
| - Guy: I've spent so much time on this. Nobody has wanted to contribute, nor has anyone provided a use-case for `export *` with CJS. I've worked with TC39 to rewrite parts of the spec for transparent interop. And then one person coming to this thread has jumped into the thread and derailed the process. This is incredibly demoralizing. If someone can provide *one* use-case, that would be minimally helpful here; along with someone willing to talk about the minimal details | ||
| - JDD: have tons of users who would be impacted by this; took a survey of code in the wild. | ||
| - Bradley: Actually didn't see that many occurrences; numbers don't entirely back that up. Many of those are occurrences are compiled code anyway. | ||
| - Jeremiah: don't think compiled code is the audience for dynamic module interop. |
There was a problem hiding this comment.
☝️ After the meeting I DM'd with @Fishrock123 (Jeremiah) to circle back to this because I suspected we were doing that thing where "transparent interop" (my bad for using that phrase) means different things to different folks. We're both in favor of loading CJS in ESM. My thing is if we go for named exports support then I’d like it fully supported without syntax traps for users. If syntax traps are unavoidable, I rather not have named exports and be consistent in more the style of --experimental-modules with just a default export to avoid complexities, or go with non-transparent interop by default with some other way (loaders, etc) to get CJS in ESM.
| - ~~15 minute timebox~~ | ||
| - 2 minute update | ||
|
|
||
| \[Out of time] |
There was a problem hiding this comment.
☝️ After the meeting I IM'd with @guybedford on the PR topic. I believe we better understand each other's POVs on this topic.
|
Will land in 24 hours if there are no objections |
Refs: #240