search

tc39 / proposal-import-attributes

Proposal for syntax to import ES modules with assertions
https://tc39.es/proposal-import-attributes/
Apache License 2.0
599 stars 26 forks source link

Enforce interoperable behavior for unsupported 'type' assertion values #111

Closed dandclark closed 1 year ago

dandclark commented 3 years ago

In https://github.com/tc39/proposal-import-assertions/issues/27 there was discussion about what to do with unrecognized types. If we want to enforce that unsupported 'type' assertion values always trigger a failure, this is one way to do it.

This change enforces that unsupported values of the 'type' assertion will trigger a failure. This is done with the introduction of the host-defined operation HostGetSupportedExtraModuleScriptTypes. Hosts will use this operation to indicate which module types (other than JavaScript) they support. If an import statement includes a type assertion that the host does not support, it will result in a syntax error (or TypeError with dynamic import()).

The result is unsupported types will be treated the same on all hosts, rather than some hosts ignoring them and some hosts triggering failure.

This change is written to avoid the scenario where a host could decide whether or not either of the following are supported:

import "./foo.js" assert { type: "js" };
import "./foo.js" assert { type: "javascript" };

In https://github.com/tc39/proposal-import-assertions/issues/49 we discussed whether these should be permitted. They are current not permitted, but if we decide to allow them in the future then that decision should be made within EcmaScript rather than by hosts. This is enforced by the requirement that these values are not present in the host's implementation of HostGetSupportedExtraModuleScriptTypes.

Alternatively we could name the HostGetSupportedModuleScriptTypes and require the host to state whether it supports JavaScript modules. But what would it mean for a host not to support JavaScript modules, if it contains module imports? We avoid the question altogether If we use HostGetSupportedExtraModuleScriptTypes and only require hosts to specify module types other than JavaScript.

ljharb commented 1 year ago

@nicolo-ribaudo this seems closeable since the semantics are pretty locked in?

nicolo-ribaudo commented 1 year ago

No one is currently pushing for this PR and it has been lying around for two years, so I'm closing this PR.

However, note that the proposed behavior matches what all the current hosts do: if someone is interested, it would be possible to bring this up again in the future as a needs-consensus PR. It's a matter of deciding where to enforce this behavior (if in ECMA-262 to ensure compatibility, or if it's ok to let hosts decide since they will very likely all end up throwing on unknown types anyway).