Add import attributes feature post

[syg]

No description provided.

[syg]

@rmahdav PTAL. We should publish this ASAP so we have something to point to for the deprecation of the assert syntax.

@dtig for lgtm stamp since @rmahdav isn't on the V8 Core GH team yet.

[syg]

Also @nicolo-ribaudo PTAL if you have some time.

[rmahdav]

@syg Thanks for the post. It looks good to me.

[nicolo-ribaudo]

Suggested change

The most important difference is that import assertions had assert-only semantics, while import attributes has more relaxed semantics. Assert-only semantics means that the additional information as part no effect on _how_ a module is loaded, only on _whether_ it is loaded. For example, a JSON module is always loaded as JSON module by virtue of its MIME type, and the `assert { type: 'json' }` clause can cause loading to fail if the requested module's MIME type is not `application/json`.

The most important difference is that import assertions had assert-only semantics, while import attributes has more relaxed semantics. Assert-only semantics means that the additional information as part no effect on _how_ a module is loaded, only on _whether_ it can be executed. For example, a JSON module is always loaded as JSON module by virtue of its MIME type, and the `assert { type: 'json' }` clause can cause loading to fail if the requested module's MIME type is not `application/json`.

Nit, but with assertions even when the module was loaded before checking the assertion, and the assertion only prevented it from being actually "executed" (if we can call execution the conversion of JSON/CSS files into JS values)

[syg]

I'm going to leave this as is. That level of understanding of "loaded" is not what's intended here, and I think using "executed" in the context of a JSON module, which developers would think of as data instead of code, would be more confusing.