-
Notifications
You must be signed in to change notification settings - Fork 31.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Importing a ".js" using esm does not show error if imported file has an "export" decl #16474
Comments
BTW, I found this out when using @jdalton's Hopefully, we'll get an |
@jdalton - I'm assuming you mean @std/esm and the non-default options of using js files? I feel a great disturbance in the force. As if millions of modules cried out in terror. :-) |
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. |
@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 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 The 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 |
Maybe we can throw a better error from the CJS loader in that case? Like |
Oh, 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. |
Assuming the following files:
One would expect that
node --experimental-modules main.mjs
would throw an error thatnot-a-module
is not an ES module and thus does not supportexport
. Rather, it throws this error:Note that running
not-a-module.js
as the main module does throw the expected error, i.e.node --experimental-modules not-a-module.js
throws an err:SyntaxError: Unexpected token export
.Also note that
node -r @std/esm
does the right thing. Just sayin' :-).The text was updated successfully, but these errors were encountered: