1 of 8

Import Assertions Update

Myles Borins, GitHub

Daniel Ehrenberg, Igalia in partnership with Bloomberg

Sven Sauleau, Babel

Daniel Clark, Microsoft

2 of 8

Proposal recap

import json from "./foo.json" assert { type: "json" };

import("./foo.json", { assert: { type: "json" } })

​

  • Assertions must not affect the host’s interpretation of the module. Can be used to only to decide whether or not to fail the import.
  • JSON modules behavior defined in a separate Stage 3 proposal: https://github.com/tc39/proposal-json-modules

​

​

3 of 8

Unsupported module types

import foo from "./bar" assert { type: "jsonn" };

​

  • Currently hosts decide what to do with unrecognized values of the ‘type’ assertion.
  • HTML will fail the module graph if there’s an unknown module type.
  • Should we standardize this behavior to drive further alignment among hosts?

​

​

​

https://github.com/tc39/proposal-import-assertions/issues/27

4 of 8

Make the host provide a list of supported types?

  • HostGetSupportedExtraModuleScriptTypes: Host hook for host to give EcmaScript the list of module types it supports
  • EcmaScript triggers a failure if an unknown type is asserted
  • Similar to HostGetSupportedAssertions

​

​

​

https://github.com/tc39/proposal-import-assertions/pull/111

5 of 8

Type restrictions problematic for some hosts

  • Some hosts want an extensible set of type assertions so that bundlers and virtualized realms and compartments can accept new types of modules.
  • Module types can be defined by author JavaScript, and there might be author-defined transforms between module types.
  • Hard to say what an "unrecognized" type is in such an environment without limiting these capabilities.

​

6 of 8

What to do?

  • My preference at this point: continue to let hosts decide what to do for unsupported module types.
  • Alternatives:
    • Enforce behavior in prose
      • Something like this in HostResolveImportedModule: “Hosts should/must return an abrupt completion if moduleRequest.[[Assertions]].type exists and is not a module type supported by the host.”
    • ???

​

7 of 8

End of presentation

Slides after this are just in case those topics arise.

8 of 8

Should Source Text Module type assertions be reserved?

import "./foo1.js" assert { type: "js" };

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

  • EcmaScript could drive interop by enforcing that these cause failure.
  • Can do this in prose, something like "None of the string values provided to HostGetSupportedExtraModuleScriptTypes may be used to import Source Text Module Records."
  • Or, enumerate the banned strings individually. How?
    • An informal registry is one option, e.g. https://github.com/littledan/js-shared-interfaces
    • Or the spec could just ban a list of the most likely candidates, e.g. “es”, “ecmascript”, ”js”, “javascript”, “source-text-module”...

https://github.com/tc39/proposal-import-assertions/issues/49