Wildcards for dynamic resolution

[brettz9]

A big part of the beauty of modules is that one doesn't need to duplicate effort in specifying dependencies within one's HTML, nor be concerned with the dependencies of one's dependencies.

Yet in the current proposal (as far as I can tell), one must both be explicit for each module about what it maps to, and requiring all dependencies to either use full paths and/or put the burden on consumers to become aware of and specify their own dependencies.

So for example:

My main application file a.js:

import something from 'b';'

File ./node_modules/b/_esm/b.js:

import something from 'c';' // at `./node_modules/c/_esm/c.js`
import something from 'c/foo';' // at `./node_modules/c/_esm/foo.js`

I need an import map explicitly mentioning both b and c. (and obviously the list could get much longer if these files had additional imports, nested or otherwise, but I'll keep it short for simplicity).

What I'd like to see as another option for import maps is something like this:

{
  "imports": {
    "*": "./node_modules/[self]/_esm/[self].js"
  }
}

The Node modules algorithm--including the module package.json enhancement--doesn't help here as it proposes no default path convention (besides the use of node_modules) as far as ESM module paths specifically, and its requirement to parse package.json is presumably too heavy to be of use.

To encourage reuse of a single path-mapping pattern, maybe one path pattern (such as the above) could be "blessed"--if not even made the sole option--such that the above code could be reproduced merely with sugar like this:

{
  "imports": {
    "*": "<esm>"
  }
}

...even while this blessed version must still be explicitly applied.

And scopes could tie into this in some manner:

"scopes": {
    "/scope2/": {
      "*": null
    }
}

...e.g., to avoid applying the node_modules/.../_esm pattern within /scope2/.

This is just to state the general idea, not to necessarily suggest using the above syntax or even leveraging the current imports and scopes properties.

[domenic]

Yep! This is a dupe of #7, so let's roll it into there. It would be a nice feature, for sure, to be explored after we have a reasonable baseline support.