Throwing TypeError in resolve a module specifier? #277
Comments
|
Yes, you're right that the propagation is a bit more complex for that caller. My plan was to convert it to catch the error and store it. |
domenic
added a commit
to whatwg/html
that referenced
this issue
Jul 5, 2022
This imports much of the specification from https://wicg.github.io/import-maps/. The main deltas are: * Does not include support for external import maps. This allows a good deal of simplification, such as by changing "acquiring import maps" + "pending import map script" + "wait for import maps" to a single "import maps allowed" boolean, or integrating "register an import map" into "execute the script element". If a src="" attribute is present on an importmap script element, then an error event is fired. * Does not include any support for non-Window import maps. The spec draft included stub support for those, with other globals always having an empty import map. This instead ties import maps to Windows directly. If we revisit that in the future we can refactor, but keeping always-empty import maps around on the other globals was clumsy. * Adds introductory text and examples. * Adds conformance requirements, both on the script element and on the import map JSON. * Fixes a few minor specification issues: WICG/import-maps#267, WICG/import-maps#267, WICG/import-maps#268, WICG/import-maps#270, WICG/import-maps#276, WICG/import-maps#277.
3 tasks
|
I believe this is fixed in whatwg/html#8075. Please check. If so, I will close this when I remove all spec text from this repository and instead let HTML be the new source of truth. |
domenic
added a commit
to whatwg/html
that referenced
this issue
Oct 5, 2022
This imports much of the specification from https://wicg.github.io/import-maps/. The main deltas are: * Does not include support for external import maps. This allows a good deal of simplification, such as by changing "acquiring import maps" + "pending import map script" + "wait for import maps" to a single "import maps allowed" boolean, or integrating "register an import map" into "execute the script element". If a src="" attribute is present on an importmap script element, then an error event is fired. See #8355. * Does not include any support for non-Window import maps. The spec draft included stub support for those, with other globals always having an empty import map. This instead ties import maps to Windows directly. If we revisit that in the future we can refactor, but keeping always-empty import maps around on the other globals was clumsy. * Adds introductory text and examples. * Adds conformance requirements, both on the script element and on the import map JSON. * Fixes a few minor specification issues: WICG/import-maps#267, WICG/import-maps#267, WICG/import-maps#268, WICG/import-maps#270, WICG/import-maps#276, WICG/import-maps#277.
domenic
added a commit
to whatwg/html
that referenced
this issue
Oct 5, 2022
This imports much of the specification from https://wicg.github.io/import-maps/. The main deltas are: * Does not include support for external import maps. This allows a good deal of simplification, such as by changing "acquiring import maps" + "pending import map script" + "wait for import maps" to a single "import maps allowed" boolean, or integrating "register an import map" into "execute the script element". If a src="" attribute is present on an importmap script element, then an error event is fired. See #8355. * Does not include any support for non-Window import maps. The spec draft included stub support for those, with other globals always having an empty import map. This instead ties import maps to Windows directly. If we revisit that in the future we can refactor, but keeping always-empty import maps around on the other globals was clumsy. * Adds introductory text and examples. * Adds conformance requirements, both on the script element and on the import map JSON. * Fixes a few minor specification issues: WICG/import-maps#267, WICG/import-maps#267, WICG/import-maps#268, WICG/import-maps#270, WICG/import-maps#276, WICG/import-maps#277.
domenic
added a commit
to whatwg/html
that referenced
this issue
Oct 5, 2022
This imports much of the specification from https://wicg.github.io/import-maps/. The main deltas are: * Does not include support for external import maps. This allows a good deal of simplification, such as by changing "acquiring import maps" + "pending import map script" + "wait for import maps" to a single "import maps allowed" boolean, or integrating "register an import map" into "execute the script element". If a src="" attribute is present on an importmap script element, then an error event is fired. See #8355. * Does not include any support for non-Window import maps. The spec draft included stub support for those, with other globals always having an empty import map. This instead ties import maps to Windows directly. If we revisit that in the future we can refactor, but keeping always-empty import maps around on the other globals was clumsy. * Adds introductory text and examples. * Adds conformance requirements, both on the script element and on the import map JSON. * Fixes a few minor specification issues: WICG/import-maps#267, WICG/import-maps#268, WICG/import-maps#270, WICG/import-maps#276, WICG/import-maps#277.
domenic
added a commit
to whatwg/html
that referenced
this issue
Oct 5, 2022
This imports much of the specification from https://wicg.github.io/import-maps/. The main deltas are: * Does not include support for external import maps. This allows a good deal of simplification, such as by changing "acquiring import maps" + "pending import map script" + "wait for import maps" to a single "import maps allowed" boolean, or integrating "register an import map" into "execute the script element". If a src="" attribute is present on an importmap script element, then an error event is fired. See #8355. * Does not include any support for non-Window import maps. The spec draft included stub support for those, with other globals always having an empty import map. This instead ties import maps to Windows directly. If we revisit that in the future we can refactor, but keeping always-empty import maps around on the other globals was clumsy. * Adds introductory text and examples. * Adds conformance requirements, both on the script element and on the import map JSON. * Fixes a few minor specification issues: WICG/import-maps#267, WICG/import-maps#268, WICG/import-maps#270, WICG/import-maps#276, WICG/import-maps#277.
domenic
added a commit
to whatwg/html
that referenced
this issue
Oct 5, 2022
This imports much of the specification from https://wicg.github.io/import-maps/. The main deltas are: * Does not include support for external import maps. This allows a good deal of simplification, such as by changing "acquiring import maps" + "pending import map script" + "wait for import maps" to a single "import maps allowed" boolean, or integrating "register an import map" into "execute the script element". If a src="" attribute is present on an importmap script element, then an error event is fired. See #8355. * Does not include any support for non-Window import maps. The spec draft included stub support for those, with other globals always having an empty import map. This instead ties import maps to Windows directly. If we revisit that in the future we can refactor, but keeping always-empty import maps around on the other globals was clumsy. * Adds introductory text and examples. * Adds conformance requirements, both on the script element and on the import map JSON. * Fixes a few minor specification issues: WICG/import-maps#267, WICG/import-maps#268, WICG/import-maps#270, WICG/import-maps#276, WICG/import-maps#277.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
According to the import maps spec, resolve a module specifier will throw,
https://wicg.github.io/import-maps/#resolve-a-module-specifier, step 12
Also the callers will be updated as well, according to https://wicg.github.io/import-maps/#resolving-updates
But what about https://html.spec.whatwg.org/multipage/webappapis.html#validate-requested-module-specifiers
According to the HTML spec, the error should be propagated to the script's parse error
https://html.spec.whatwg.org/multipage/webappapis.html#concept-script-parse-error
and later it will be the error to rethrow object of the script.
https://html.spec.whatwg.org/multipage/webappapis.html#concept-script-error-to-rethrow
So in this case, should 'resolve a module specifier' still throw a TypeError if it has any?
Or it should return failure (like the original 'resolve a module specifier' does), and let script to propagate the error?
Note: V8's implementation is in
JSModuleScript::Create
ModulatorImplBase::ResolveModuleSpecifier
and
ImportMap::Resolve
The text was updated successfully, but these errors were encountered: