Use general key-value syntax, or a single string?

[littledan]

In the original thread at WICG/webcomponents#839, there are several suggestions of syntax which includes a single string, rather than key-value syntax. Let's discuss the advantages and disadvantages of this option in this thread.

For example, the syntax for an import statement could be:

import json from "./foo.json" as "json";

Advantages of a single string

• Less to type: save 6 characters of "type: ". Including the type will be annoying enough as is!
• Less overall complexity for the syntax and semantics
• Less to coordinate across environments (c.f., Use cases for module attributes besides module type #8, h/t to @MylesBorins for raising this issue)

Advantages of key-value syntax

• Generalizes to other use cases (c.f., Use cases for module attributes besides module type #8). Additional module parameters was an idea tossed around from even before this issue, so even if we don't find one of those use cases persuading now, we have some circumstantial evidence that it may come up in the future.
• If we don't provide a general k/v syntax, there's a chance that people will see the need to do so inside the string (as was already proposed for the module specifier, see Should a syntax within module specifiers be used for this data instead? #11)
• The as keyword is likely to be pretty confusing, as it's also a keyword with completely different meaning in other parts of an import statement

My opinion is that the advantages of a general key-value syntax outweigh the advantages for a single string. It's circumstantial evidence (since this proposal doesn't suggest acting on any of them yet), but the relatively high number of other possible use cases points to a k/v syntax to me. This would be analogous to the decision to make import.meta an object, rather than just adding a syntax for import.meta.url.

[chicoxyzzy]

Key-value syntax is definitely look like a more future proof solution to me. Also this will make static imports and dynamic imports look more consistent, or are there any other suggestions than import('module', { type: 'json' }) which look more like a single string solution for static imports?

[bahrus]

Could the type be treated as the default, but if more parameters need to be defined, switch to k/v syntax? I.e a hybrid approach? The analogy of the default export, which doesn't use braces when importing comes to mind.

[Janpot]

Can't there still be key/value syntax with a single string, if encoded as a querystring?

import json from "./foo.json" as "type=json&anotherOption=42";

// and default behavior
import json from "./foo.json" as "json";
// would be equivalent to
import json from "./foo.json" as "type=json";

[littledan]

@Janpot We could do that. My feeling is that more sub-syntaxes will lead to more problems, from a developer experience perspective, from possible diversity/bugs in parsers, etc.

[Janpot]

My feeling is that it would leave more freedom to hosts/compilers on how to parse that string. My understanding is that the spec doesn't dictate how the module identifier is interpreted, I feel like in the same way it could leave freedom on how the module attributes are interpreted.

[littledan]

Well, this comes a bit in contrast with the goals articulated in #10

[Janpot]

I see. fwiw, I didn't necessarily mean "freedom" as in "no consensus". I meant it more like "allow enough escape hatch for people to come up with ideas that we didn't think of today"

[bmeck]

I'd like to call out editor UX here. Key-Value will lead to better completions if we ever have multiple attributes (which I would consider a mandate for this feature personally). Even today I am given sub-par UX with import statements due to their design and would not like to have another UX pitfall here for import.

[Janpot]

@bmeck Are you talking about it being hard to autocomplete the import since you type the module specifier last? As in, it would be more ergonomic to do:

from 'lodash' import { groupBy };

[bmeck]

@Janpot that syntax allows tooling to better complete the code as you type, which is my concern yes.

[littledan]

@bmeck I am with you on completions. I think you should usually not have to type the type at all if using editor completions.

[thw0rted]

Has anybody made a strong argument against supporting both?

import j1 from "./foo.json" as "json";
import j2 from "./foo.json" as {type: "json", bar: "baz"};
const j3 = import("./foo.json", "json");
const j4 = import("./foo.json", {type: "json", bar: "baz"});

The thing I keep coming back to is that nobody can give me a concrete example of what the bar attribute should be. Of course it makes sense to save those 6 characters if the proposal never grows beyond type:, but if another attribute comes along and is not only useful but more commonly specified, having a "shorthand version" that's always interpreted as being the type will seem short-sighted in retrospect. At this point, to me, the opposite seems more likely: that we're currently over-engineering a solution for the general case (bag of key-value attributes) when the immediate need is for a simple case (exactly one attribute).

[littledan]

Well, the basic concern would be that this goes in contrast with goals of minimalism. In the OP, I had some concerns with using as as a keyword here as well.

[xtuc]

@thw0rted I think there are many use case for more than one argument: #22 or #16 (comment) are one of them in this repo.