Fallbacks for failed URLs?
trusktr opened this issue · 1 comments
The biggest hassle I have so far with managing import maps by hand is that, depending on the install method, modules can be nested, or not.
The issue:
Sometimes I bootstrap a bunch of packages with Lerna. This results in:
my-app/
node_modules/
A/
node_modules/
B/
because B is a dependency of A, and A is symlinked into my-app by Lerna (where my-app is one of multiple projects managed by Lerna in, for example, a monorepo).
This leads me to write an importmap like so:
<script type="importmap">
{
"imports": {
"A": "/node_modules/A/index.js",
"B": "/node_modules/A/node_modules/B/index.js",
}
}
</script>
Other times, if I run npm install
directly inside of my-app then I get flat modules:
my-app/
node_modules/
A/
B/
This leads me to write an importmap like so:
<script type="importmap">
{
"imports": {
"A": "/node_modules/A/index.js",
"B": "/node_modules/B/index.js",
}
}
</script>
If I have the first importmap in my project, and then perform an flat install, it breaks. If I have the second importmap in my project and perform a linked install, it breaks.
Is there a solution to this?
Maybe I'm missing something, but do scopes solve this? If so, I haven't had any luck yet, and from the text, it seems like the provide an absolute final mapping, not that failed fetches would fall back.
What I'm imagining here is that a mechanism would try the scoped value, it gets a failure, then falls back like scope does. If this is already the case, I can't get it to work.
I've tried the following, hoping that it would fall back on a failure, so that it works with either install method without needing to update the importmap
every time I change install method:
<script type="importmap">
{
"imports": {
"A": "/node_modules/A/index.js",
"B": "/node_modules/B/index.js",
},
"scopes": {
"/node_modules/A/": {
"B": "/node_modules/A/node_modules/B/index.js",
}
}
}
</script>
A workaround is to make all the transitive dependencies be direct dependencies of my-app
in its package.json
, so that Lerna will place them at the top level of node_modules besides in the linked modules, then the install format won't matter.
I suppose this workaround does make dependencies more "wholesomely" in my control as the app author.