Supporting Common JS Named Exports using ES Module Imports
See original GitHub issueHello & good day! Since the latest release, the import { version } from './package.json
and other imports from JSON files is broken for Node.JS module resolution.
import { version } from '../package.json'
console.log(version)
Version: v20190301 Built on: 2019-03-05 23:14 with
-jar node_modules/google-closure-compiler-java/compiler.jar
--compilation_level ADVANCED
--module_resolution NODE
--js t/package.js package.json
produces console.log("0.0.1-alpha");
Whereas the update has now made it not possible 😦
Exit code 1
t/package.js:2: ERROR - variable null is undeclared
console.log(version)
^^^^^^^
1 error(s), 0 warning(s)
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 require
and --process_common_js_modules
btw:
const { version } = require('../package.json')
console.log(version)
Issue Analytics
- State:
- Created 4 years ago
- Comments:8 (4 by maintainers)
Top Results From Across the Web
CommonJS vs. ES Modules: Modules and Imports in NodeJS
NodeJS allows us to import CommonJS modules from ES Modules. If we would like to import our CommonJS class export example from above,...
Read more >Node.js now supports named imports from CommonJS ...
First Things First: What are named exports? This syntax allows you to only import specific named exports from an ES module – in...
Read more >When can a CommonJS named export be imported by an ES ...
Named exports detection covers many common export patterns, reexport patterns and build tool and transpiler outputs. See cjs-module-lexer for ...
Read more >CommonJS vs. ES modules in Node.js - LogRocket Blog
In the browser JavaScript ecosystem, the use of JavaScript modules depends on the import and export statements; these statements load and export ......
Read more >Modules • JavaScript for impatient programmers (ES2022 ...
27.6 Named exports and imports. 27.6.1 Named exports ... With CommonJS, ES modules share the compact syntax and support for cyclic dependencies.
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
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:
It’s only the destructuring style of import that has the issue.
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
default
export when referenced from an ES Module. CommonJS does not have named exports.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.