Supporting Common JS Named Exports using ES Module Imports #3308
Comments
|
This is by design. The interop between CommonJS and ES Modules is defined by NodeJS and has gone through several iterations (there's yet a new one coming). The last supported version stated that CommonJS modules only have a The latest proposal and work effort can be found at https://github.com/nodejs/modules/blob/master/doc/plan-for-new-modules-implementation.md This is a complex issue and at this point I'd really like to see that this version will actually happen before implementing it in Closure-Compiler. Also - it's likely to include breaking changes so this could be a bit painful. The good news is that the Node community seems to be taking all the developer backlash to the last version to heart and is working hard to address that in the newest version. |
|
thanks |
|
I realize the frustration here - it's pretty much felt by the entire dev community right now. We got here directly because a transpiler (Babel) made decisions that weren't actually able to be natively implemented. However If Closure Compiler deviates from the current spec, we'll be making the problem worse - not better. Then when the spec gets figured out, we'll have to migrate our dev community to the proper way and that can be painful too. Just as a note, the following should work just fine: import pkg from '../package.json'
console.log(pkg.version)It's only the destructuring style of import that has the issue. |
ChadKillingsworth
changed the title
|
Created internal issue http://b/129802304, although it sounds like this is WAI to me. |
blickly
added
internal-issue-created
|
It is - until Node figures out whether they are natively going to support CommonJS named exports, I don't want to support them in Closure Compiler. There is a strong desire to support these, but they don't know how to do it yet or what that would look like. The full discussion is at nodejs/modules#264 but I can't really tell what the current state of things is by that issue. |
|
@ChadKillingsworth thanks for the advise about import packageJson from '../package.json'throws now also I'm very sorry for my tone in the first comment, I do apologize I felt really terrible and ashamed of myself hence only now got to check the responses ( import test from 'test'
test.default.test('hello world')? this is insane. on top of that no IDE supports that sort of programming, well at least VS Code but it I'm pretty sure nothing else does. if i'm trying to import something, I know what I'm doing don't i? what's the point of making the code looking crazy as well as destroying developer experience, just for the sake of some imaginary standard/babel? oh well i'm glad there were difficulties like that they make make new solutions and improve everything else that comes inbetween. |
|
I'll look into the crash and see what's causing that. As to your example, that's not quite right. CommonJS has a default export (that's the ONLY export it has). import test from 'test'
test.test('hello world')Of course that's assuming the module.exports.test = function(msg) {}; |
|
@ChadKillingsworth well it's not been implemented correctly I'm afraid then because // ecma
import commonJs from './common-js'
console.log('requiring a common js from ecma:')
console.log(commonJs)// common-js
const commonJs2 = require('./common-js2')
module.exports = () => {
console.log('default common js export')
}
module.exports['named'] = () => {
console.log('named common js export')
}
console.log('requiring a common js from common js:')
console.log(commonJs2)// common-js
module.exports = () => {
console.log('default common js export2')
}
module.exports['named'] = () => {
console.log('named common js export2')
}-jar /Users/zavr/node_modules/google-closure-compiler-java/compiler.jar --compilation_level ADVANCED \
--language_out ECMASCRIPT_2017 --formatting PRETTY_PRINT \
--process_common_js_modules --package_json_entry_names module,main \
--entry_point /Users/zavr/depack/depack/example/commonjs/index.js \
--module_resolution NODE \
--js /Users/zavr/depack/depack/example/commonjs/index.js
/Users/zavr/depack/depack/example/commonjs/common-js.js
/Users/zavr/depack/depack/example/commonjs/common-js2.jsOUTPUT 'use strict';
var a = () => {
console.log("default common js export2");
};
a.named = () => {
console.log("named common js export2");
};
var b = {default:() => {
console.log("default common js export");
}};
b.default.named = () => {
console.log("named common js export");
};
console.log("requiring a common js from common js:");
console.log(a);
console.log("requiring a common js from ecma:");
console.log(b);Execution: Also read more about fun with Babel here. This is how it can be used... import erte from '@a-la/fixture-babel'
console.log(erte.default.default())
console.log(erte.default.c())
console.log(erte.default.b()) |
Hello & good day! Since the latest release, the
import { version } from './package.jsonand other imports from JSON files is broken for Node.JS module resolution.Version: v20190301 Built on: 2019-03-05 23:14 with
produces
console.log("0.0.1-alpha");Whereas the update has now made it not possible :(
I'm now wondering if importing JSON files is actually part of Ecma6 but I don't see why it shouldn't be for at least for Node Module resolution in Closure.
If works with
requireand--process_common_js_modulesbtw:The text was updated successfully, but these errors were encountered: