Propagation of search/hash fragments about import-maps

[domenic]

I don't think that's productive; I'd rather keep the discussion in the issue.

[domenic]

I don't think there's a reason to start blocking characters at the spec level, but if you find them confusing I definitely can understand you not wanting to use them in your own package names.

[bmeck]

@domenic I would state that they should be blocked if they do not act like separators do in other specifiers. I'm not convinced of the need for package name map specifiers to not be parsed as base URLs and would seek guidance on why they shouldn't be treated as such otherwise.

[bmeck]

I must be getting confused on terminology, what is the term of a specifier like:

<img src="foo?bar">

[domenic]

That is a relative URL-string; it is resolved relative to the document's base URL.

Such strings are prohibited for modules; relative URLs can only appear with a ./, ../, or / prefix.

[domenic]

Hmm, I don't think this is how it should behave. Instead that should expand to look for a package named "moment?tz=utc".

[bmeck]

@domenic I would disagree given that import.meta.url is propagating the fragments and you can add fragments via import '/node_modules/src/moment.js?tz=utc'. What is being gained by expansion using package name maps treating ? and # not as fragments and propagating them like other specifiers? Why should it behave differently?

[domenic]

Package names are not URLs; they are opaque strings.

If you use a URL, you can use URL features like ? and #. If you use a package name, then you're supplying a package name for lookup in the map, and URL characters don't have a special meaning.

[bmeck]

It seems from the discussion in the other issue that you can do import 'foo/bar?baz' though? import 'foo/?baz' as well. Specifiers such as foo/?bar, /foo?bar, ./foo?bar, etc. passing these around but not if you exclude the / for package name mapped specifiers seems odd. They might not be URLs but is there a reason to neither reserve the characters nor preserve consistency of being able to use these features?

[domenic]

Right, the portion after the package name is a URL.

I don't think it's consistency to treat certain characters specially in this one case; I think it's rather inconsistent. We're not going to do full URL parsing (e.g. percent decoding and friends), so pulling out a few characters that the URL parser treats specially and then adding our own new semantics (different from the URL parser) on top decreases consistency.

[bmeck]

@domenic in that case it seems like prohibiting those characters in package names would prevent confusion without adding new semantics. Allowing those characters seems unnecessary and confusing when you can end up with x?x/?x. It seems fine to take that approach as well, but doesn't really get into the fact that you have a main Module that cannot be passed fragments like other module specifiers.

[domenic]

They cannot be parsed as base URLs, since they do not conform to the URL syntax (e.g. there is no protocol or colon).

[bmeck]

I'll make a PR about banning the characters for now due to both confusion and potential future reservation I guess and we can continue discussion there.

[bmeck]

it looks like no progress can be made on the issue, moving responsibility of matching to Node instead.