-
Notifications
You must be signed in to change notification settings - Fork 44
Locking down fragment/query on bare package names #83
Comments
\cc @iarna for npm since it's package name related. |
In the current implementation the above falls into the ResolveModule path at https://github.com/nodejs/node/blob/master/src/module_wrap.cc#L594. Which then concatenates the specifier into the node_modules lookup. Once found, the path is taken to be the part after the package name length. So the above example would check the directory So we're actually already pretty locked down and in agreement with the package map approach here. |
Wouldn't this also impact how folks were planning to handle reloading modules |
@jdalton to an extent? @guybedford that is a good catch and would have been considered a bug if I saw it before this issue. Since it was not my intention when writing that to have that specific behavior it seems we should still talk about it though. |
I have to admit that this seems counter-intuitive to me. Maybe logical, but counter-intuitive: If I do import './foo?x=4' Then I import the file But if I do import 'foo?x=4' Then we're importing the package in the folder/file While I understand the logic—bare imports are not URLs, and should not be treated as such—I believe most people wouldn't understand this and would be surprised by this behavior, especially if import 'foo/bar?x=4' is treated (somewhat) as a URL and the In the interest of the principle of least-surprise, I hope it doesn't land this way. |
@giltayar you can post the issue I created in package name maps, but I did not see a way to argue about it if prohibiting the characters is seen as a bad idea. Any way it goes, we should match package name maps. |
Conclusion should stand and we aren't discussing this anymore. |
Right now hash/search fragments are preserved when importing new URLs:
will load 2 different modules and use these fragments as being passed to the
"main"
entrypoint offoo
. This goes against how package name maps are seeking to work WICG/import-maps#38 . We should do a couple things to get in line with the package name map behavior if that is what we are seeking to use for web compatibility./
as part of the package specifier for these bare import specifiers. meaning that package names can contain?
or#
.?
or#
get a message about if the prefix would have been found.The text was updated successfully, but these errors were encountered: