query parameters / fragments on "exports"?

[bmeck]

I couldn't find on a quick search if there was intended behavior on "exports" preventing usage of query parameters and/or fragments.

import('foo/bar?n=1')

Will not load a ./bar export from foo currently it seems.

[jkrems]

I think I agree with Domenic's reasoning on the import maps proposal and would say "f?x and f are two separate and potentially mappable strings".

This does mean that if a tool wants to cache bust, they would have to resolve (~import.meta.resolve) the bare specifier to a URL first and then add query params.

[bmeck]

I find it odd that, resolve('f?x') and new URL(resolve('f')) += '?x' are different.

Though, I also find how data: is treated as opaque and not respecting query/fragment also odd on WHATWG side of things, it doesn't match IETF interpretation. Right now data: is does have query string/fragment in Node and also is not a hierarchical URL.

[jkrems]

I think adding first-class query parameters to bare specifier parsing opens a whole can of worms. We would have to define a grammar and/or normalization scheme. By design, the matched specifiers aren't URL path segments. They can include spaces, emojis, URL special characters, it doesn't really matter. Node only does prefix matching and a trailing slash is the only recognized syntax beyond that.

[bmeck]

I'm fine with the direction we have, but strongly don't agree with the reasoning provided in the import maps issue. We should just add docs.

[bmeck]

closing as avoided