Overwriting the headers instead of creating new custom syntax

[franciscop]

Sorry for being late to the party. My proposal is to, instead of creating a new way of naming a header, overwrite the Content-Type server-side header through this syntax:

import json from "./foo.json" with { "Content-Type": "application/json" };
import("foo.json", { "Content-Type": "application/json" });

Why?

• It's more legible as plain English: "import X (variable) from Y (source) with Z (headers)". Assert seems like testing, not like overwriting content-type.
• Uses a concept already wildly familiar for those doing Javascript (headers) instead of introducing a new/different ones that are normally used in other contexts (type is an HTML attribute and not even the right one because of asserttype, assert is normally used for testing)
• It's more clear that is setting the response Content-Type, while in the current proposal just by looking at the statement it's not clear if it's doing content-negotiation (Accepts) or resolution as intended (Content-Type).
• Reusing the protected keyword with in a new context instead of creating a new keyword.
• Avoids colliding types that require nesting like new Worker('my-app.wasm', { type: 'module', assert: { type: 'webassembly' } }) (by using new Worker('my-app.wasm', { type: 'module', Content-Type: 'webassembly' })

This might seem similar as issue #85, but this issue is about overwriting the response headers, not about content type negotiation.

[ljharb]

There’s no such thing as a header in ecma-262, or in non-browsers (for non-http imports, that is)

[bmeck]

I would note that assertions do not allow alteration or overriding of the headers, they are merely an integrity check. Changing headers would go to a separate evaluators proposal : https://github.com/tc39/proposal-import-assertions#follow-up-proposal-evaluator-attributes

[xtuc]

@franciscop is that a satisfying answer to you? we discussed that in the past. Can I close the issue?

[littledan]

I think this proposal is a bit too low-level: it's more verbose and feels less likely to work the same across environments.

[franciscop]

"they are merely an integrity check"

Oh sorry I missed that from the proposal, then yes this is fine!