Matching with multiple trailing slash entries

[hiroshige-g]

{
  "imports": {
    "a": "/1",
    "a/": "/2/",
    "a/b": "/3",
    "a/b/": "/4/"
  }
}

a/b/c matches a/ and a/b/, and thus might be mapped to /4/c or /2/b/c, respectively. Also, a/b matches a/ or a/b, and thus might be mapped to /2/c or /3, respectively.

Should we

• Reject this kind of import maps?
• Or refine the matching rule to remove ambiguity? For example, by using the longest match (in this case a/b/c should match with a/b/, and a/b should match with a/b).

The current ref impl seems to choose an matching entry based on the Object.entries() order.

[domenic]

Somewhat related: https://github.com/WICG/import-maps/issues/73 for scopes. Although there we definitely need to support more-specific-wins, whereas here it's less clear.

I suspect that either:

• Overlapping import specifiers are useless, and we should disallow them because they are confusing.
• There is some use case for them, where most-specific wins would be the expected behavior.

So among the four behavior options I think we should pick one of those two (disallow or most-specific-wins).

Does anyone have use cases where most-specific-wins would be expected? If we don't hear of one that's important, then I'd lean toward disallow, at least for now, since it's easy to expand in the future.

From an implementation complexity standpoint, I guess that disallowing adds some complexity and performance loss to the parsing phase, while most-specific-wins adds some complexity and performance-loss to the resolution phase. Does that sound right?

[guybedford]

Here is a use case. Node.js is considering at some point implementing an "exports" map which would be defined in a way that is compatible with package maps generation. See https://github.com/jkrems/proposal-pkg-exports.

These maps allow folder-level mappings within a package, for example:

{
  "exports": {
    "./timezones/": "./data/timezones/"
  }
}

for the above package.json export map, the generated package map for a package named pkg would look like:

{
  "imports": {
    "pkg/": "/path/to/pkg/",
    "pkg/timezones/": "/path/to/pkg/data/timezones/"
  }
}

thus supporting this would be critical to the operation of such a workflow.

If package maps were to ban this higher specificity in subpaths, then package export maps in Node.js would have to disallow trailing slash paths entirely.

Map configuration in AMD and SystemJS loaders is always based on the most-specific, so that is what users are used to as well.

I personally think highest-specificity makes sense and would provide worthwhile symmetry with scopes.

//cc @jkrems

[guybedford]

In terms of algorithmic complexity, we discussed this in https://github.com/WICG/import-maps/issues/73#issuecomment-439327758. It seems a simple binary search would be more than adequate initially.

[jrburke]

“Specificity wins” was useful for tests, allows swapping in a mock or alternate implementation.

Also for bug fixing/modifying one module in a package you don’t control/publish, can provide a fix in the one module without maintaining a fork of the whole package. But perhaps the cost of the fork maintenance is not high enough to see it as a primary use case here.

[ljharb]

Without “specificity wins”, any mapped directory means that nothing inside it can be overridden - in other words, it means that creating a mapping for any directory prevents any deeper override within it, making mapped specifiers second class to unmapped ones.

[hiroshige-g]

Thanks for comments!

From an implementation complexity, I don't expect the options (disallow or most-specific-wins) affect overall complexity so much.

Also +1 to https://github.com/WICG/import-maps/issues/102#issuecomment-464358016

I'm drafting an initial CL with the most-specific-wins rule.