Sugary defaults: can we create a simple case for advanced ahead-of-time tools?

[domenic]

As mentioned in "A convention-based flat mapping", it'd be ideal to also support a way of doing a very simple package map for applications which are laid out ahead of time in a conventional way on-server. For example, you could imagine something like

{
  "imports": {
    "*": "/node_modules_flattened/$1/index.js"
  }
}

In offline discussions, @nyaxt cautioned that this would add a lot of complexity to what was so far a simple format. For example, as-written this would presumably work at any level of the tree. Still, it'd sure be nice...

An alternative is to not reuse the same format, but instead come up with something specifically tailored for this use case, that only works at top level. As a straw-person, you could do:

{
  "pattern": "/node_modules_flattened/*/index.js"
}

[bmeck]

package-community/discussions#2 is relevant

I would like to note my dislike if this would cause diverging package ecosystems.

[domenic]

I'll note that this also is important if we want to enable people who are not using package managers to use bare import specifiers without a lot of manual synchronization between their filesystem and their package map.

For example, imagine someone who downloads libraries as zip files and unzips them into a /js/assets/ directory. I don't think too many folks visiting this repository will still be doing that, but it's worth having sympathy with a good fraction of developers who still might. (Or do we think that any libraries that produce native modules will insist you download them via packages? I guess it's not quite clear yet...)

Or imagine a tutorial that says something like "insert these lines into your page and now you can use any package on npm:"

{
  "pattern": "https://normalized.unpkg.com/*/index.js"
}

(Here "normalized.unpkg.com" is a hypothetical variant of unpkg that ensures a top-level index.js is always the main module, somehow.)

[nyaxt]

I'm not against adding this, but I strongly prefer to not have this in the first cut. I think we can carefully add this later.

[trusktr]

Adding .js to every import is redundant. Can this feature cover a simple way to automatically make it so all extension-less specifiers use .js?

[jkrems]

After trying out prefix-matching with many existing packages in node.js (and based on feedback from bundlers), it looks like the bare specifier mapping there may move away from prefix and instead always suggest using a syntax that's very similar to this.

Since import maps haven't shipped widely yet, this may be an opportunity to prevent confusion on the browser side and "just" never add prefix-matching. For the cases where prefix-matching behavior is the actual desired behavior, it can be expressed with fairly limited overhead using basic pattern support:

{
  "imports": {
    // before:
    "components/": "/static/app/components/",
    // after:
    "components/*": "/static/app/components/*",
    // or with the syntax in OP:
    "components/*": "/static/app/components/$1",
  }
}