CommonJS import interoperability decisions #264
Description
As @MylesBorins mentioned in #261, there are some things we need to vote on. I was thinking that we should start with the biggest topic: support for import
statements/expressions bringing CommonJS files and packages into ESM. That’s probably the biggest decision we have to make, in terms of the effect it has on the implementation we’re building and eventually shipping; and making this decision will probably take up most if not all of the time in the meeting, so there’s probably no point in preparing votes on anything else. Here are some questions that I propose we put to votes at a meeting:
-
Do you support
import
interoperability of CommonJS in theory? As in, could there potentially be any implementation that satisfies you for allowingimport
statements andimport()
expressions of CommonJS files and packages? (If this question is voted “no,” we can skip the rest.) -
Do you support full CommonJS
import
interoperability via two-phase execution (CJS named exports via two-phase execution ecmascript-modules#31) if that turns out to be the only CommonJSimport
interoperability method that wins majority support? -
Do you support almost-full (all but
export * from
) CommonJSimport
interoperability via dynamic modules (WIP [Do not merge] - Irp type dynamic modules ecmascript-modules#29), if that turns out to be the only CommonJSimport
interoperability method that wins majority support? -
If both of the above PRs win majority support, which one do you prefer?
-
If neither of the above PRs win majority support, do you prefer to keep the current
--experimental-modules
/ecmascript-modules “default export only” CommonJS import (soimport _ from 'underscore'
but notimport { shuffle } from 'underscore'
) or would you prefer to remove CommonJSimport
interoperability altogether?
I tried to phrase these neutrally; if people have feedback I’ll edit this post. Please feel free to make your case for your preferences in this thread 😄