Change keyword «with»

[inoyakaigor]

Keyword with already exists. Maybe better define MIME type like this:
import module from 'module' as 'json'?

[chicoxyzzy]

I don't see any problems with with in this context, it looks clean. Also type is sufficient part of syntax, it shouldn't be omitted. What I think about is if another option will be introduced, for example

const foo = import('module', { type: 'json', anotherOption: 42 })

than, how should static modules syntax look like?

import foo from 'module' with type: 'json', otherOption: 42; // ?
import foo from 'module' with type: 'json', with otherOption: 42; // ?

I'd prefer something like

import foo from 'module' with { type: 'json', anotherOption: 42 }

[xtuc]

I don't feel strongly about using vs with, they seem similar to me.

@inoyakaigor
The syntax

import module from 'module' as 'json'

is more concise, but doesn't allow arbitrary attributes on the ImportDeclaration. This proposal will support more features than the type in the future.

@chicoxyzzy
A json object seems more consistent because it's a known syntax. The module's attributes are static, people might use the attribute as a regular object like:

import foo from 'module' with { type: 'json', anotherOption: process.argv }

I think adding a new syntax would remove that confusion. Or is this something we would like to allow?

[littledan]

An issue with as is that it's already part of import syntax, in a different position. with would be new and non-overlapping in this context. Anyway, I acknowledge that it's been pounded into everyone's head that with is bad, so maybe we should avoid it ....

[devsnek]

object literals as xtuc posted is not possible because you'd have to evaluate a module to know if it shouldn't be evaluated. We could use object syntax with only literals or something, but that seems confusing. I'd imagined something like

import 'x' with y: 'z', a: 'b';

[littledan]

@devsnek Yeah, that's what I'd imagine too. To me, the curly braces make me feel like you could use any expression there, which you can't.

[justinfagnani]

I'm proposing that with is reused for mixin application in: https://github.com/justinfagnani/proposal-mixins

Would this be too many separate meaning?

[chicoxyzzy]

in this statement

import 'module' with type: 'json';

'json' looks like an expression too. What literal types should be allowed in with? Only strings and numbers?

[chicoxyzzy]

In the hypothetical situation with a bunch of options when the import string becomes too long curly brackets also look better IMHO

import 'module' with
  type: 'json',
  anotherOption: 6 * 7, // should that be allowed?
  ...
  lastOption: 'hello' + 'world'; // should that be allowed?

vs

import 'module' with {
  type: 'json',
  anotherOption: 42_000n, // should that be allowed?
  ...
  lastOption: `hello ${'world'}`, // should that be allowed?
}

[devsnek]

the exact grammar should be entirely primitive literals

[chicoxyzzy]

so

import 'module' with something: Symbol();

should be a valid grammar too?

[devsnek]

@chicoxyzzy that's not a primitive literal, that's a call expression.

[chicoxyzzy]

Oh, right. In that case, my only concern is that since with values are somewhat limited (could only be primitives), there is no big difference between

import 'module' with
  type: 'json',
  anotherOption: 42n,
  ...
  lastOption: 'hello world';

and

import 'module' with {
  type: 'json',
  anotherOption: 42n,
  ...
  lastOption: 'hello world',
};

Though, curly braces option looks better and could allow trailing comma.

[chicoxyzzy]

Also those limitations look very similar to Can't convert Object with a non-const value part from Tuples and Records proposal example so perhaps some logic could be reused for with part of import statement

[chicoxyzzy]

Maybe it's even better to use record syntax there

import 'module' with {|
  type: 'json',
  anotherOption: 42n,
  ...
  lastOption: 'hello world',
|};