Closed sheerun closed 4 years ago
If you import lodash/first.js
does that resolve to /node_modules/lodash-es/first.js.js
? If not how does the algorithm know if it should append the extension or not?
@matthewp The extension would be added only if:
imported package is not found as exact match in import-map and no extension is provided
lodash/first.js
already has an extension, it's mapped to /node_modules/lodash-es/first.js
Does the web platform have an algorithm for determining an extension?
If not you'd need to come up with one. The presence of a dot doesn't work because some times filenames contain a dot that is not for the extension, for example foo.bar.js
is a valid filename. We would want lodash/foo.bar
to resolve to /node_modules/lodash-es/foo.bar.js
@matthewp the extension there is only .js
, the .bar
is part of the filename - certainly it would be a new thing for the web platform to apply that algorithm, but it's a pretty well-established convention everywhere else.
@ljharb Yes, but if the import is import "lodash/foo.bar"
it needs to know if the .bar
is the extension or part of the filename. How does it know?
Files do not need to have extensions. In this world, how would I import the file at lodash/first
?
I agree that by default there should be no extension logic applied; but it seems like it should be possible for me to say "everything in this import map scope should automatically have a suffix applied to the RHS, if it doesn't endWith() it" - we don't even have to call it an "extension".
Also need to think about what happens when there are multiple types of modules. For example if we have wasm modules, the endsWith()
algorithm means you couldn't import those. You'd probably need both a defaultExtension
property and a validExtensions
array so that you can tell the algorithm that lodash/first.wasm
doesn't need the .js append.
I'd use a different import map scope for those.
Yeah, the proposal requires you to always provide file extensions. (...) The default path encourages you to be explicit.
This issue proposes way to be at the same time explicit and allow extension-less imports.
Could you explain why you don't want to allow extension-less imports even if they can be explicitly configured with import map?
The readme is fairly explicit about this: https://github.com/WICG/import-maps#extension-less-imports. It's not encouraged, but if you really want to do it, you can generate a giant import map.
I've already commented about the quote you link here: https://github.com/nodejs/modules/issues/444
This looks like by-design flaw that could be solved by something as simple as proposed option.
This issue provides a way to explicitly and simply configure extension-less imports in import-map, can solve https://github.com/nodejs/modules/issues/444 and also can solve issue you are linking to. Why not allow it?
Referencing: https://github.com/nodejs/modules/issues/444 and #7
Node could theoretically implement extension-less imports for ES6 modules but the main argument against is that it's not possible to statically generate import map for extension-less imports like
import first from 'lodash/first'
(without listing each possible file in import map).This use case could be rather easily solved by allowing to specify default extension to add if imported package is not found as exact match in import-map and no extension is provided.
For example:
would make
import first from 'lodash/first'
to import/node_modules/lodash-es/first.js
instead of/node_modules/lodash-es/first
.Arguably this could be also made a default behavior. No pattern matching like proposed in #7 is really necessary for 99% of cases.