Allow type in the cache key, and only pass that to the host

[nicolo-ribaudo]

This PR:

• changes the proposal to only pass type to the engine, reserving everything else for future use
• more explicitly allows type to be part of the cache key
• changes the keyword from assert to with, since it's not just asserting anymore

This is a draft. Please don't focus on the exact syntax, but on the general idea.

Ref whatwg/html#7233, https://gist.github.com/peetklecha/a55532165dbd4905aa91bbe59e8b1001

Preview: https://raw.githack.com/nicolo-ribaudo/proposal-import-assertions/attributes/dist/index.html

[aduh95]

The Node.js TSC has discussed the recent change of import assertions from stage 3 to 2. We support TC39’s efforts to improve this proposal, and we want to communicate that we agree with the Chromium/V8 team that our preference would be that the syntax not change. Import assertions have been unflagged in Node.js for over a year, including in our LTS release lines (16.x and 18.x), and it would be a disruptive change for our users to reflag the feature. Lacking some indication whether the current syntax will remain unchanged, we plan to resume requiring a runtime flag for using import assertions in Node.js 20.0.0; we would need to make that decision by April 1st. We expect this move to be quite breaking for some of our users. Would it be possible for the TC39 to communicate a (hopefully final) decision regarding the syntax during the March meeting?

[guybedford]

After some discussion I'm also starting to come around on the compat argument brought up by @aduh95 in retaining the syntax. That we have a year of unflagged usage in Node.js and Deno is certainly a strong consideration to make.

Regarding this spec change in particular, I was wondering if rather than specializing on the "type", it would be beneficial to treat the local linkage as keyed by the exact attributes list for now. Just like a relative and absolute URL can have two key entries pointing to the same module, it would still be possible to share instances via host-level deduping. This would at least set up a framework for other types to be able to support unique reinstancing as required.

[nicolo-ribaudo]

@aduh95 I will present #131 in the March meeting. While the preference of the champions is to migrate from assert to with, there are different possible final outcomes:

• we decide to stick with only assert
• we have both assert and with for a while (1 year? 3 years? 🤷) to give web developers the time to migrate. JS code using assert has been written recently, so there is an high chance that it's still maintained. At some point, the usage of assert will have decreased enough that it's considered compatible to completely remove it.
  • For example, Node.js could start warning in 20.0.0 unless the flag is specified, throwing in 21.0.0 unless the flag is specified, and remove the flag in 22.0.0.
• we end up having both assert and with forever

(I can't post this in nodejs/node#46830, feel free to copy it if you want!)

[nicolo-ribaudo]

Closing in favor of #131