Skip to content
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

Closed
nicolo-ribaudo opened this issue Jun 8, 2023 · 5 comments · Fixed by #65
Closed

Missing sources should throw a *SyntaxError* when imported #49

nicolo-ribaudo opened this issue Jun 8, 2023 · 5 comments · Fixed by #65

Comments

@nicolo-ribaudo
Copy link
Member

nicolo-ribaudo commented Jun 8, 2023

Right now this code throws a ReferenceError, because there are no JS source objects:

import source s from "./mod.js";

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 export x.

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).

@guybedford
Copy link
Collaborator

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.

@nicolo-ribaudo
Copy link
Member Author

Re discussed about this in a modules harmony call, what was the resolution?

@guybedford
Copy link
Collaborator

I believe there were no strong opinions. If you still feel strongly towards SyntaxError please feel free to go ahead.

@legendecas
Copy link
Member

legendecas commented Sep 22, 2024

FWIW, the error types in failed import calls (like module not found) are not defined in ecma262.

HTML spec throws TypeError in most conditions, like mismatched module type, resolution error or network error, and SyntaxError for unknown keys in import attributes (Step 7.1.1.1).

Node.js throws Error with Node.js error code ERR_MODULE_NOT_FOUND when module is not found.

I'd wonder if a module that has no source should be TypeError instead since the syntax is correct but the module is unable to be imported in a source form. Specifically, in HTML import call like import.source('wasm-module'), the module type is determined by MIME type that was extracted from the http response header and if 'wasm-module' has an incorrect MIME type, the import call would fail but the syntax is correct.

@nicolo-ribaudo
Copy link
Member Author

FWIW, the error types in failed import calls (like module not found) are not defined in ecma262.

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 x".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants