Created
March 22, 2016 15:34
-
-
Save jbrantly/29969e8448d40538832a to your computer and use it in GitHub Desktop.
The problem with the CJS-ES6 gap
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
| // ES6 exports | |
| export var foo = 1 | |
| export var bar = true | |
| // CJS analog | |
| module.exports = { | |
| foo: 1, | |
| bar: true | |
| } | |
| // Importing all exports from the above ES6 module | |
| import * as mod from 'module' | |
| // I think it can be argued that if you're allowing CJS to be imported using ES6 syntax, then | |
| // the above CJS module could also be imported using: | |
| import * as mod from 'module' | |
| // However, if you allow the above, then it in turn also means you can do this: | |
| // CJS module | |
| module.exports = function foo() {} | |
| // Importing... | |
| import * as func from 'module' |
I heavily recommend people use import mydefault from 'foo' over * when doing interop with CJS.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Actually there are a bunch of differences that are visible from ModuleNamespaceObjects, it should become pretty apparent for some cases like
module.exports = Promise.resolve(1)since.thenwould fail (anything usingthisfor that matter will probably have problems), primitives would be boxed as objects, the namespace is frozen so it is read-only and cannot be extended. Explaining hoisting is just something that will have to be done if we want named imports to work with CJS.