Comments (16)
Currently everything after the package name is a path internal to the package, so you have to include the full filename:
import { map, filter, mergeMap } from 'rxjs/operators/index.js';
Or, you can define another nested package:
{
"packages": {
"rxjs": {
"path": "rxjs",
"main" : "index.js"
},
"rxjs/operators": {
"path": "rxjs/operators",
"main": "index.js"
}
}
}
Packages defined in the map do not have to correspond to npm packages.
from import-maps.
Think about packages like @babel/runtime
, where you're always supposed to import a nested path (since there isn't a main
entry point for the whole package). I'm hoping we can avoid listing out every single (sub-)subdirectory and module in packages like that.
from import-maps.
Ok, thanks for clarifying. This is already the case.
Once you define the path for @babel/runtime
everything after the package name in a specifier is just a path in the package folder. The configuration you gave works.
from import-maps.
from import-maps.
wouldn't that be:
{
"packages": {
"rxjs": {
"path": "rxjs",
"main" : "index.js"
},
"rxjs/operators": {
"path": "rxjs/operators",
"main": "operators/index.js"
}
}
}
?
from import-maps.
No, because the value of main
is joined to the package path.
Also, if we add a shorthand form that contains both path
and main
in a single string, we might be able to write:
{
"packages": {
"rxjs": {
"path": "rxjs",
"main" : "index.js"
},
"rxjs/operators": "rxjs/operators/index.js",
}
}
But I'm unsure how this would work if you also wanted to allow access to other modules within rxjs/operators
, like rxjs/operators/first.js
. We haven't talked about the short form implying a path mapping for the dirname of the main file.
from import-maps.
Cool.. I'm satisfied with that answer... but it sounds like there are still some open questions. Do you want me to leave this issue open?
from import-maps.
Yeah, leave it open so we can add an example of this.
from import-maps.
If you were willing to write
import { map, filter, mergeMap } from 'rxjs/operators/index.js'
then hopefully there would be no need to include rxjs/operators
in the package map explicitly, since the existing entry for rxjs
could be used to interpret the rxjs/operators/index.js
identifier, by looking up the path of rxjs
and then path-joining operators/index.js
to it?
In other words, is it accurate to say that including rxjs/operators
in the map is only necessary because you want to specify a default index.js
to be appended to rxjs/operators
?
from import-maps.
I’d certainly say that’s an important use case, since it’s the convention used in most npm packages (omitting extensions and relying on directory searching). By allowing these to be precomputed into a package map, then code wouldn’t need to be modified to run in a browser.
from import-maps.
What's the problem with requiring file extensions?
@babel/runtime/helpers/toArray
just isn't much shorter than @babel/runtime/helpers/toArray.js
from import-maps.
I am totally in favor of requiring file extensions!
What I want to avoid is having to list out every single @babel/runtime/helpers/...
bare identifier in the package map. Hopefully you could just say
{
"packages": {
"@babel/runtime": {
"path": "/path/to/@babel/runtime"
}
}
}
and that would be enough to make import "@babel/runtime/helpers/toArray.js"
work without explicitly saying anything about the helpers
subdirectory or its contents in the package map.
from import-maps.
@justinfagnani it's not about "short", it's about "compatible with existing best practices in the npm ecosystem", which are to always omit the extension in require/import paths.
from import-maps.
@MylesBorins the current best practices are for "i want my require/import to be more robust against refactoring", and ESM, WASM, etc, will add "robust against changing of the module format, where possible". I think abandoning that resolution mechanism in node would be a terrible idea, but we can discuss that in the appropriate venue.
from import-maps.
Are there an explicit specificity-resolution semantics that should be discussed in the proposal?
In the context of original question, do we have an algorithm for determining which top-level package entry should be chosen?
"packages": {
"rxjs": {
"path": "rxjs",
"main" : "index.js"
},
"rxjs/operators": {
"path": "rxjs/operators",
"main": "index.js"
}
}
}
Intuitively, we know that the latter should be used for rxjs/operators
but I don't think I saw anything that states this explicitly.
Consider the example of import { flatSmoosh } from 'rxjs/operators/flatSmoosh';
; the top-level package specifier chosen should be the most specific one, I think.
from import-maps.
The proposal has changed a lot, so let me close this; if it's still unclear in the new proposal let me know.
Concretely, the answers are still fairly similar, but things are a bit less verbose.
from import-maps.
Related Issues (20)
- Modulepreload error caching HOT 9
- Should HTMLScriptElement.supports("importmap") return true? HOT 1
- Fire a load event or an error event when the script element of the import map is from an external file? HOT 2
- preparation-time document check should be done first at #register-an-import-map HOT 2
- Throwing TypeError in resolve a module specifier? HOT 2
- calling onerror of the script element if the import map string cannot be parsed HOT 1
- What should 'parse an import map string' return when it throws an Error? HOT 8
- Speculatively parsing with import map if there's a dynmic import before, HOT 4
- Official file extension? HOT 2
- Support stars in imports besides trailing slashes HOT 1
- `importmap` cannot resolve dependencies entered relatively. HOT 3
- [feat] `script.integrity` and import map HOT 2
- Specification is not restricting address from containing query- or fragment parts not ending with "/" HOT 3
- global variables (f.e. map `"jquery"` specifier to `globalThis.jquery` variable) HOT 1
- Specify package.json path in <script>, and then generate the import map from package.json. HOT 7
- Unable to create folder alias to use in further alias. HOT 2
- ability to specify a default extension for extensionless URLs HOT 3
- Fallbacks for failed URLs? HOT 1
- import maps for `import()` statements HOT 1
- Support for "package.json browser" style file replacement/removal within modules? HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from import-maps.