Import Attributes

[xtuc]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Import attributes
• Specification or proposal URL: https://github.com/tc39/proposal-import-attributes
• Caniuse.com URL (optional):
• Bugzilla URL (optional):
• Mozillians who can provide input (optional):

Other information

Currently Stage 2.

[dbaron]

cc @codehag @annevk @jorendorff @tschneidereit @linclark

[hober]

Note that this feature (or something like it) is necessary to move forward on HTML/CSS/JSON modules.

[tschneidereit]

Also CC @lukewagner. Does it make sense to think about how this interacts with Wasm module linking?

[xtuc]

The proposal has a WebAssembly section. It wouldn't be in TC39 but our plan is to allow to express the same attributes than in JavaScript. The Wasm producer will need some syntax, or can based on the file extension.

[lukewagner]

The use of a custom section to allow wasm modules imported via ESM-integration to import non-wasm/JS modules seems like a reasonable approach. Other than that, there's not any interaction I can think of with wasm module linking until "evaluator attributes" are added (which it sounds like is explicitly postponed). So 👍 from a wasm pov.

[codehag]

I discussed this with @annevk some time ago - it's worth pursuing with a few caveats. However, those have been met before stage 2 (we considered inbound syntax as important, as otherwise it might not be used). I don't think our support has changed since. 👍

[littledan]

@lukewagner Do you think "evaluator attributes" would be useful for expressing permissions/capabilities for Wasm modules?

[annevk]

@xtuc note that Wasm should not use the file externsion on the web as that would be counter to how the web works.

[lukewagner]

@littledan I think so: evaluator attributes would allow JS code to pass the import values used to instantiate a wasm module (either to limit capabilities or to allow explicit parameterization) while still getting to use the ESM module loader system. To do so without evaluator attributes, you need to resort to using the imperative JS API and manual fetch()ing.

[dbaron]

So does it make sense to mark this as worth prototyping, or are there things that should happen before we're willing to do that?

[codehag]

I think we can mark it as worth prototyping

[dandclark]

This proposal was renamed to "Import Assertions" to reflect the keyword we ended up settling on (assert), and to reflect that the presence of the attributes won't affect the behavior of a module, only block it from loading (as opposed to potential "evaluator attributes").

The old URL in activities.json will redirect to the renamed proposal so it's probably not critical to change anything, but we just wanted to keep everyone updated.

[dandclark]

At the time that this position request was originally marked worth prototyping, JSON modules was part of the import attributes proposal. Since then, JSON modules has been split off into a separate proposal: https://github.com/tc39/proposal-json-modules
(This was decided here: https://github.com/tc39/notes/blob/master/meetings/2020-07/july-21.md#conclusion--resolution-2). The actual behavior of JSON modules has not changed in any significant way.

Because of this split, the position at da63152 is now ambiguous; it references JSON modules but the spec it links to no longer contains JSON modules.

Would it be possible to update this position to include https://github.com/tc39/proposal-json-modules, or add a new position entry for JSON modules?

In case it's relevant, JSON modules is now a Stage 3 proposal (as is import assertions).

Thanks!

[codehag]

Hi @dandclark, In this case, I don't think we need to explicitly update it, since I gave support for it at TC39 for stage 3 and that was mozilla's position both then and now. We have started implementing both.

cc @tantek

[dandclark]

Ok, thanks @codehag ! It's great to hear that the implementation is underway.

[danielweil]

Any updates on this issue implementation?

[ekr]

This is not the place to look updates on implementation in Gecko. Perhaps @codehag can add the bugzilla link?

[codehag]

Import assertions is finished https://bugzilla.mozilla.org/show_bug.cgi?id=1736059

As it is still at stage 3, we haven't shipped it unflagged yet, but the flag for enabling it is experimental.import_assertions. We have an external contributor working on JSON modules, which is the first "assertion" that will be exposed. You can ask further questions on https://bugzilla.mozilla.org/show_bug.cgi?id=1670176.

[321paranoiawhy]

Hi, I can not use import assertions in FireFox version 103.0.2 (64 位).
What I get is Uncaught SyntaxError: import assertions are not currently supported in the console.
I wonder what happens exactly as the version of FireFox is up-to-date.
But this can be used successfully in my chrome whose version is 版本 104.0.5112.81（正式版本）.
How can I detect current browser supports or not this feature?
Hope your help, thanks a lot.

[myakura]

@321paranoiawhy it's not shipped yet https://bugzilla.mozilla.org/show_bug.cgi?id=1777526

[juner]

@321paranoiawhy Try using the following code.

async function enableWithTypeSyntax() {
  let enableWithTypeSyntax = false;
  const option = (() => {
    const option = {};
    const w = {type:"json"};
    Reflect.defineProperty(option, "with", {
      get: () => (enableWithTypeSyntax=true,w),
    });
    return option;
  })();
  let result;
  try {
    const importMethod = new Function("dataUrl", "option", "return import(dataUrl, option);");
    result = await importMethod("data:application/json;base64,e30=", option);
  }catch(e){}
  return enableWithTypeSyntax;
}

playground