Avoid adding a new keyword for static imports (with)

[michael-ciniawsky]

Wouldn't it be possible to avoid the e.g with keyword for static imports by e.g

// Module
import module from 'url';
// Module with Attributes 
import module from ('url', attrs);

e.g

import module from './file.js';
// equal to
import module from ('./file.js', { type: 'js' });

with the benefit of being kind of similiar to the syntax of a dynamic import?

import module from ('./file.js', { type: 'js' });

import('file.js', { type: 'js' }).then((module) => module)

My apologies if this was already being discussed/proposed before

[littledan]

I haven't seen another discussion of this particular alternative. Could you say something about why you see this option as preferable? (Personally, I thought a keyword would be in keeping with the rest of the syntax of import statements.)

[michael-ciniawsky]

Could you say something about why you see this option as preferable?

ℹ️ The following list is in no particular order

1. It should be easier to parse
2. It's more inituitive (subjective of course) with a familiar syntax like a function call or import()
3. In terms of using module attributes the syntax would be quite similiar to dynamic imports

import module from ('./file.wasm', { type: 'wasm' });

const module = await import('./file.wasm', { type: 'wasm' });

4. If overtime more attributes should be added I find the current syntax hard to read and it seems the concrete syntax of how this would look like seems to be 'undecided' upon, I assume, since I couldn't find any examples (maybe I missed them)

import module from './file.wasm' with type: 'wasm', integrity: '7425tre...'
// Aside: Would this be valid? (newline)
import module from 'file.wasm' with 
  type: 'wasm', // Comma separated?
  integrity: '7425tre...'

// Proposed alternative
import module from (
  './file.wasm', 
  { type: 'wasm', integrity: '7425tre..' }
);



const module = await import(
  './file.wasm', 
  { type: 'wasm', integrity: '7425tre..' }
);

Some of the examples simply looked kind of verbose when I first read them, so I was wondering if that's on purpose (It's needed/required by some contraints) and this popped up as an alternative in my mind :)

Personally, I thought a keyword would be in keeping with the rest of the syntax of import statements.

Sure :), but allowing a 'parenthesized referrer' instead of adding a new keyword shouldn't 'voilate' the current syntax for import statements with the benefit of having more alignment between import statements and import() 'for free' *

import json from "./foo.json" with type: "json";
import("foo.json", { with: { type: "json" } /* <= Meh ;( */ })

import json from ("./foo.json", { type: "json" });
import("foo.json", { type: "json" } /* <= no with { .. }  for alignment needed */)

[michael-ciniawsky]

How do Import Maps work together with Module Attributes? Is this needed/or a goal at all? e.g ( only in theory to make a showcase :) )

import-map.json

{
  "imports": {
     // Module (Current)
    "[referrer]": "[url]"
     // Module with Attributes (Proposed)
    "[referrer]": {
          url: "/node_modules/wasm-pkg/module.wasm",
          type: 'wasm',
          deps: [ ./dep1.wasm', './dep2.wasm' ], // e.g DepCache Proposal @guybedford
          integrity: '...'
    }
}

// Import Maps
// Module (with Attributes)
import module from '[referrer]';
const module = await import('[referrer]')

// Without Import Maps 
// Module
import module from "/node_modules/wasm-pkg/module.wasm";
// Module with Attributes
import module from (
  "/node_modules/wasm-pkg/module.wasm",
   { type: 'wasm', deps: [ './dep1.wasm', './dep2.wasm' ], integrity: '...' }
);

const module = await import(
  "/node_modules/wasm-pkg/module.wasm",
   { type: 'wasm', deps: [ './dep1.wasm', './dep2.wasm' ], integrity: '...' }
);

[littledan]

1. I think both versions are pretty easy to parse. (Definitely easier than import statements as a whole!)
2. Yeah, I agree this is subjective; I guess I have the opposite opinion. I think positional arguments, generally, have the potential to increase confusion.
3. I don't know whether you really want these things to be in 100% the same--import declarations are hopefully a bit nicer to use in general.
4. Yes, the idea is to be comma-separated. We're open to including the curly brackets in the import statement, see Use object-literal-like notation for attributes? #5 for more discussion

As for whether import() should have the one-level or two-level argument, that's another kind of orthogonal decision that we could bikeshed over, and has been discussed previously in this repo (sorry I'm not sure where exactly, maybe @xtuc has a cross-reference).

For depcache and integrity, I think these are better expressed out-of-band exclusively. When we have a piece of metadata that makes sense both in-band and out-of-band, we can think more concretely about how we could let users do either. I'd imagine, out-of-band could set a baseline, and in-band could add more things to that.

[trusktr]

How do Import Maps work together with Module Attributes? Is this needed/or a goal at all?

Besides what you said (which seems to mean that yes we would need to consider how import maps work with this), seems like they would need to be handled in some way if there will be something like #73

[littledan]

About import maps, I've proposed things about interactions with import maps in the past, but they weren't considered in scope for the people working on import maps. I'm not currently proposing more things about import maps.

[nicolo-ribaudo]

The proposal has settled on the import [bindings] from [source] with { [key1]: [string1], [key2]: [string2], ... } syntax, with the dynamic import equivalent being import([source], { with: { [key1]: [string1], [key2]: [string2], ... } }).

Thanks for contributing to the discussion!