Should type: "js" work?

[dandclark]

Not sure if this has been discussed yet, but it occurred to me that we should consider allowing "js" (or maybe the full "javascript") as a valid value for the type key, e.g.:

import {whatever} from "./foo.js" with type: "js";

Which would be exactly equivalent to just:

import {whatever} from "./foo.js";

Pro: Consistency. It could be surprising to developers that specifying the type for "js" is is an error while other module types require it to be specified. Con: Now there would be two ways to do the same thing since JS is the default.

Thoughts? I'm leaning towards saying that it should be supported but this is not a strongly held opinion.

[devsnek]

type: 'source-text-module' perhaps, but not type: 'js'

[MylesBorins]

I disagree with that suggestion Gus. We are not making it type: 'text/json' specifically because folks shouldn't have to know about internals.

Maybe type: 'module'?

On Thu, Mar 26, 2020, 5:22 PM Gus Caplan notifications@github.com wrote:

type: 'source-text-module' perhaps, but not type: 'js'

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/tc39/proposal-module-attributes/issues/49#issuecomment-604693528, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADZYV56VEPUTJFOY6IJGWDRJPBPXANCNFSM4LURBAXQ .

[devsnek]

@mylesborins maybe my intent was lost... all these modules are modules, but I assume the suggestion here is about modules authored as source text ecmascript modules. type: module seems like a tautology to me, all modules are modules.

[Jack-Works]

Allowing a "js" type may simplify the code generation work

[littledan]

I'd suggest omitting this. We will have to support the case where no type is specified. Is there really that significant of a benefit to include multiple ways to spell this case?

(The type: "module" suggestion seems pretty confusing to me, since all of these things are modules... The notion of type here does not correspond to classic/script vs module. I'd prefer type: "js" or type: "javascript" if we include one of these.)

[littledan]

I want to suggest: we can come back and add this between Stage 2 and 3 (or even later, after initially shipping, why not), but that we don't need type: "js" for a basic proposal when assessing coherence/viability of it. So I think coming to a conclusion on this question blocks Stage 3, but not Stage 2.

[xtuc]

If an enviroment would want to only load modules with a type attribute we need to allow JS, however I'm not convienced that developers would use it if not necessary.

[Jamesernator]

I imagine people would want to use it in dynamic imports just for completeness e.g.:

const types = {
    ".js": "js",
    ".wasm": "webassembly",
    ".json": "json",
    ".html": "html",
}

const module = await import(url, { if: { type: types[getExtension(url)] } });

[guybedford]

"type": "javascript" is currently not implemented in Chrome. While a missing type is treated as JS equivalent in the spec, I think it would be useful to have further implementation guidance from the spec if hosts are expected to implement this type or not, which also relates to the JS / WebAssembly assertion discussion. If guidance is still unclear here then that should also be clarified in the spec.

[GeoffreyBooth]

If guidance is still unclear here then that should also be clarified in the spec.

In https://github.com/tc39/proposal-import-assertions/issues/114 I suggested that the proposal include type: 'javascript' to align with the HTML spec. Basically, the lack of an assertion type implies type: 'javascript', and cannot imply any other type.

[ljharb]

That's not what was discussed in plenary, where consensus (as i recall) was to allow hosts to make any number of optional types that can mean the same thing as "no assertion".

[ljharb]

There's the additional piece that Ecma doesn't own the copyright to the word "javascript" and I'm not sure if we'd be able to encode that in the spec.