-
Notifications
You must be signed in to change notification settings - Fork 8
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
Missing sources should throw a *SyntaxError* when imported #49
Comments
This is still somewhat of a semantic question since source phases aren't really associated with any execution, they are more like slots on the module map. We could similarly say that this is more like TDZ, since the slot is there but it is not filled. Note also that modules in cycles with TDZ provide reference errors when attempting to access a binding from a module which has not yet been executed. That all said, I don't have strong opinions and am open to changing the error type, but some further discussion could be worthwhile. |
Re discussed about this in a modules harmony call, what was the resolution? |
I believe there were no strong opinions. If you still feel strongly towards SyntaxError please feel free to go ahead. |
FWIW, the error types in failed import calls (like module not found) are not defined in ecma262. HTML spec throws Node.js throws I'd wonder if a module that has no source should be |
On the other hand, errors for modules that are found, are valid, but that you are trying to read something that does not exist from them throw a SyntaxError in 262: import { x } from "./x.js"; // SyntaxError // x.js
export const y = 2; I'd argue that "this module doesn't expose its source" is similar to "this module doesn't expose |
Right now this code throws a ReferenceError, because there are no JS source objects:
I believe this code should throw a SyntaxError, even if might appear conter-intuitive. ReferenceError is only used for code that runs, and not before evaluation. As a very strong precedent ("very strong" because it's basically the same thing),
import { x } from "./a"
is a SyntaxError is./a
does not exportx
.Older versions of the language used to have ReferenceErrors for some errors that happen before evaluation, but in ES2020 we updated all of them to be SyntaxErrors (tc39/ecma262#1527).
The text was updated successfully, but these errors were encountered: