-
Notifications
You must be signed in to change notification settings - Fork 72
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Values with trailing slashes not in path part #173
Comments
Hmm. This seems OK-ish; the intention of the rule is mostly to catch potential errors. However it seems like it would be pretty easy to add one additional check, that the trailing slash is in the path. I guess it would become harder to insert such a check after #167, because then the right hand side is no longer necessarily a URL. /cc @bakkot @michaelficarra. |
I think it'd still be pretty easy to add this check after #167; URL-based specifiers on the right-hand side already need to be normalized, and there could be an additional check at that point forbidding query parameters or fragments when the left hand side is a package prefix. This would involve adding an additional My opinion on the issue: The {
"imports": {
"moment/": "/node_resolver.php?path=moment/"
}
} (Of course one could rewrite their server in such a way that the resource ended up in the actual path of the URL, but why should they have to?) So adding this check, at least for the query parameter case, seems like it would rule out useful cases, and I'm not convinced it rules out any commensurately large class of error. The |
Also, re: the {
"imports": {
"a/": "/a#foo/",
"b": "/b#bar"
}
} |
@bakkot on the last point, there can be value in the definition of: {
"imports": {
"b": "/b#bar"
}
} as the |
In a related issue, I propose a syntax that would allow the excess segments "matching" the The addition of this feature would dedramatize the choice of where the excess segments are placed by default. |
It seems like we're OK with the consequences of the current spec, so I'll close this. Happy to reopen if there's something we missed. |
#176 reverts the trailing-slash behavior back to pre-#164 (still I'm neutral):
|
As of current, does the spec allow using import maps to route imported modules through a single endpoint passing their path via a fragment or a search param like shown in this snippet by @bakkot? {
"imports": {
"moment/": "/node_resolver.php?path=moment/"
}
} I am hoping to find a way to achieve this: <script type="importmap">
{
"imports": {
"./index.js": "./index.js",
"./": "./launder.js?/"
}
}
</script>
<script type="module" src="index.js"></script>
import test from './test.js';
console.log(import.meta.url, test);
console.log(import.meta.url);
export default import.meta.url; In this scenario, in my preferred case, I would like to see |
Originally from @nyaxt:
For keys ending with slashes, we require values to end with slashes, but any slashes (not necessarily in the path part) are OK. So for example
https://foo.com/bar/baz
is mapped tohttps://nyaxtstep.com/fox?grapes=/bar/baz
https://foo.com/bar?baz
is mapped tohttps://nyaxtstep.com/fox?grapes=/bar?baz
https://bar.com/baz
is mapped tohttps://nyaxtstep.com/fox#/baz
(The behavior before d5add26 is different though)
I don't have strong opinions here; WDYT? Does this looks good?
The text was updated successfully, but these errors were encountered: