Skip to content
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

Add caveats to extension-less imports example #111

Merged
merged 1 commit into from Mar 9, 2019

Conversation

Projects
None yet
5 participants
@domenic
Copy link
Collaborator

domenic commented Mar 8, 2019

This is a follow-up to #109.

/cc @devsnek

@devsnek

devsnek approved these changes Mar 9, 2019

@@ -207,6 +207,12 @@ It is also common in the Node.js ecosystem to import files without including the

would allow not only `import fp from "lodash/fp.js"`, but also allow `import fp from "loadsh/fp"`.

Although this example shows how it is _possible_ to allow extension-less imports with import maps, it's not necessarily _desirable_. Doing so bloats the import map, and makes the package's interface less simple—both for humans and for tooling.

This bloat is especially problematic if you need to allow extension-less imports within a package. In that case you will need an import map entry for every file in the package, not just the top-level entry points. For example, to allow `import "./fp"` from within the `/node_modules/lodash-es/lodash.js` file, you would need an import entry mapping `/node_modules/lodash-es/fp` to `/node_modules/lodash-es/fp.js`. Now imagine repeating this for every file referenced without an extension.

This comment has been minimized.

@ljharb

ljharb Mar 9, 2019

Since this is a common use case (most of npm atm), is it worth pursuing how important maps could meet it while avoiding the bloat (wildcards, namespaced suffixes, or something), instead of hoping that the wider community consistently reads and complies with this warning?

This comment has been minimized.

@domenic

domenic Mar 9, 2019

Author Collaborator

I think we have enough work to do with import maps that improving the performance for people who aren't willing yo use extensions is not going to make it onto the use case list.

This comment has been minimized.

@ljharb

ljharb Mar 9, 2019

I’m more suggesting that people are going to do this regardless, so if that incurs a size cost, it’d be useful for import maps to have a better story there. Understood that it’s not a priority.

@@ -207,6 +207,12 @@ It is also common in the Node.js ecosystem to import files without including the

would allow not only `import fp from "lodash/fp.js"`, but also allow `import fp from "loadsh/fp"`.

Although this example shows how it is _possible_ to allow extension-less imports with import maps, it's not necessarily _desirable_. Doing so bloats the import map, and makes the package's interface less simple—both for humans and for tooling.

This bloat is especially problematic if you need to allow extension-less imports within a package. In that case you will need an import map entry for every file in the package, not just the top-level entry points. For example, to allow `import "./fp"` from within the `/node_modules/lodash-es/lodash.js` file, you would need an import entry mapping `/node_modules/lodash-es/fp` to `/node_modules/lodash-es/fp.js`. Now imagine repeating this for every file referenced without an extension.

This comment has been minimized.

@jkrems

jkrems Mar 9, 2019

For example, to allow import "./fp" from within the /node_modules/lodash-es/lodash.js file, you would need an import entry mapping /node_modules/lodash-es/fp to /node_modules/lodash-es/fp.js.

This currently reads like import maps apply after URL resolution. Is that correct? My understanding was that they apply before URL resolution..? Example:

  • "/foo/bar": "/foo/zapp" - for the exact specifier "/foo/bar", replace with "/foo/zapp", then resolve URL based on base to https://origin.com/foo/zapp.

Or is the import map tried multiple times, once on the original string and once on the URL after resolution relative to the base? If it is only looked at before resolution relative to the base/referrer, then shouldn't "./fp" require its own unique entry in the import map and wouldn't be caught by "/node_modules/lodash-es/fp"?

This comment has been minimized.

@domenic

domenic Mar 9, 2019

Author Collaborator

If a specifier is URL-like, e.g. starts with ./ or ../, then URL resolution applies. See #112 or the reference implementation for more details.

@guybedford
Copy link
Collaborator

guybedford left a comment

Nice to have these caveats explicitly explained.

@domenic domenic merged commit 84e4a08 into master Mar 9, 2019

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

@domenic domenic deleted the extensionless-caveats branch Mar 9, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.