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

Import assertions proposal renamed to import attributes #29572

Closed
nicolo-ribaudo opened this issue Oct 10, 2023 · 5 comments · Fixed by #33856
Closed

Import assertions proposal renamed to import attributes #29572

nicolo-ribaudo opened this issue Oct 10, 2023 · 5 comments · Fixed by #33856
Labels
Content:JS JavaScript docs

Comments

@nicolo-ribaudo
Copy link
Contributor

nicolo-ribaudo commented Oct 10, 2023

MDN URL

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import

What specific section or headline is this issue about?

No response

What information was incorrect, unhelpful, or incomplete?

That page mention import assertions, with the import ... assert { ... } syntax.

What did you expect to see?

The proposal has been renamed to "import attributes", and the keyword has been replaced from assert to with. assert is now "deprecated and should not be relied upon".

Do you have any supporting links, references, or citations?

https://tc39.es/proposal-import-attributes/, specifically https://tc39.es/proposal-import-attributes/#sec-deprecated-assert-keyword-for-import-attributes.

Do you have anything more you want to share?

Chrome is the only browser implementing assert (and V8-based platforms).

Chrome implements with under a flag (and V8-based platforms), Safari implements with in TP and Firefox is implementing it.

The proposal update comes also with some semantic changes, however these details have never been documented so there is no change needed to the docs:

@nicolo-ribaudo nicolo-ribaudo added the needs triage Triage needed by staff and/or partners. Automatically applied when an issue is opened. label Oct 10, 2023
@github-actions github-actions bot added the Content:JS JavaScript docs label Oct 10, 2023
@Josh-Cena
Copy link
Member

Josh-Cena commented Oct 10, 2023

@nicolo-ribaudo The only place that mentions assertions is the browser compat, which is accurate because it indeed had been and probably is still shipped in browsers, and we don't remove their mention until they have been unshipped for two years. I will be writing docs for import attributes, but I still don't fully appreciate attributes' differences with assertions (what runtime effects do they have exactly? Are they essentially part of the specifier?), and I'm currently still working on set methods, so this one will wait until it has a bit more implementation.

@Josh-Cena Josh-Cena removed the needs triage Triage needed by staff and/or partners. Automatically applied when an issue is opened. label Oct 10, 2023
@nicolo-ribaudo
Copy link
Contributor Author

nicolo-ribaudo commented Oct 12, 2023

The main difference is that unknown attribute keys throw an error rather than being ignores (i.e. import ... with { unknown: "" } is an error). A minor difference is that the type: "json"/type: "css" will now affect the Accept HTTP header used to fetch the imported module.

I will open a PR for compat data for engines supporting with :)

@Josh-Cena
Copy link
Member

I will work on a PR next week when I'm on break. Would appreciate your review by then ;)

@Josh-Cena
Copy link
Member

Josh-Cena commented Nov 25, 2023

@nicolo-ribaudo I've started the documentation process, but since this has impacts beyond what's reflected in the spec, I want to ask a few clarifying questions.

  1. Does with { type: "json" } have the same "assertion" semantics as assert? Could you check https://github.com/mdn/content/pull/19588/files#diff-26bbf25f7d10742cc1d8f38fd1c6cc60c752aa63d2f82415ffd8eb87aee82308 and see if that draft still accurately reflects the motivation and behavior of JSON modules?
  2. What are all relevant discussions to read on JSON/CSS/HTML module integration in the HTML spec? Particularly attributes' influence on the HTTP headers? I think the original explainer (https://github.com/WICG/webcomponents/blob/gh-pages/proposals/css-modules-v1-explainer.md) is far outdated and I don't want to scroll through the HTML spec, so GitHub PRs would be best.
  3. I still have the lingering question: "what runtime effects do they have exactly (as permitted by the ES spec)?" For example, am I right in thinking that with { type: "source" } can achieve the same effect as import source, barring caching, etc.? Can it influence the host's behavior at every stage during fetching, parsing, and loading in arbitrary ways as the host desires?

Thank you for the help!

@nicolo-ribaudo
Copy link
Contributor Author

Does with { type: "json" } have the same "assertion" semantics as assert?

No, with allows passing parameters to the loader in general. Some of these parameters could be used as assertion, but they could also be used for anything else. For example, with { type: "json" } has three effects:

  • it uses the connect-src CSP directive to decide whether the module can be loaded, rather than script-src used by JS
  • it passes an Accept HTTP header to the server describing that it expects a JSON respnse
  • it asserts that the mime type returned by the server is indeed a JSON mime type

assert also doesn't have "assertion" semantics anymore, but it become just a legacy alias for with (and hopefully we'll remove it one day).

What are all relevant discussions to read on JSON/CSS/HTML module integration in the HTML spec? Particularly attributes' influence on the HTTP headers?

Mostly whatwg/html#7233, whatwg/html#9486, and tc39/proposal-import-attributes#125

I still have the lingering question: "what runtime effects do they have exactly (as permitted by the ES spec)?" ...

They can affect how a module is resolved, how it's fetched, and how it's parsed. Basically every stage that transforms the import specifier to a Module Record (a spec construct that basically exposes metadata about the module and a function to evaluate it).

So yes, with { type: "source" } could behave like import source, except that it gives less guarantees about a module being "the same" when imported as a source and as a full module.

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

Successfully merging a pull request may close this issue.

2 participants