Repository navigation
Importing a ".js" using esm does not show error if imported file has an "export" decl #16474
Description
Activity
BTW, I found this out when using @jdalton's
lodash-esmodule, which exposes the esm modules as.jsfiles, and couldn't figure out why importing a specific function fromlodash-eswasn't working.Hopefully, we'll get an
mjs-ed version oflodashin the near future. :-)- changed the title
[-]Importing a ".js" using es m does not show error if imported file has an "export" decl[/-][+]Importing a ".js" using esm does not show error if imported file has an "export" decl[/+]on Oct 25, 2017 One would expect that node --experimental-modules main.mjs would throw an error that not-a-module is not an ES module and thus does not support export.
Why, though? The main script is deliberately importing it as a module. I wouldn't expect Node.js to second-guess me here. In fact, I'd be rather annoyed if it did.
Reacted by ExE Boss and Chris Anderson@bnoordhuis - I understand, but those are not the rules of the game as have been defined by the TSC in regards to ESM in Node. According to the rules - a file is an es module if and only if extension is mjs.
There have been lots of discussions around that, which I would not want to bring into this bug - this bug assumes the rules are as already defined.
It seems like a more general bug. I get this error even when the imported module has the
.mjsextension.Edit: no, sorry my test was wrong.
The way this happens is that the "commonJS shell" for "not-a-module.js" is instantiated fine to
{ default }which happens before the CommonJS modulenot-a-module.jshas even been read, or evaluated. This is because CommonJS is not read or executed until the later execute phase.The
main.mjsmodule is then instantiated next, and sees that it doesn't have the exports it needs, which throws at that stage of the pipeline. The execute phase is then never reached.If we were to have CommmonJS execute during the instantiation phase then we could show the right error, but that would mess with the execution timings that
import 'a'; import 'b'; import 'c';will execute in a deterministic tree execution order (for both CJS and ESM).Maybe we can throw a better error from the CJS loader in that case? Like
CJS modules only have a default exportOh, wow. It took me a while to figure out what you were saying, @guybedford, but it gives me a glimpse of how the whole thing is working.
I believe fixing this bug is crucial for people starting to work on migrating from cjs to esm. There will be enough confusion as it is during this migration phase, and having confusing error messages wouldn't be beneficial. It took me a while to figure out what the problem was, and I am deep into trying to understand ESM in Node (for a talk I am giving).
Maybe, as an edge case, if you don't find the correct import, then execute (or, even better, just parse) the module knowing that it is a CJS module (from the extension), and throw the correct error if you figure out that it has ESM syntax inside it.
I would hate to suggest this, because it sounds like a hack, but as I said above, I believe it crucial to to living in a dual CJS-ESM world, which is probably our world for the coming years.
Possibly related to c8a389e#commitcomment-24187496.
Over a year with no update, so I'm going to close this.
Feel free to ping me if this should be reopened.
Assuming the following files:
One would expect that
node --experimental-modules main.mjswould throw an error thatnot-a-moduleis not an ES module and thus does not supportexport. Rather, it throws this error:Note that running
not-a-module.jsas the main module does throw the expected error, i.e.node --experimental-modules not-a-module.jsthrows an err:SyntaxError: Unexpected token export.Also note that
node -r @std/esmdoes the right thing. Just sayin' :-).