Open schlichtanders opened 5 months ago
I stumbled upon the resolution flag which seems to be the option to solve these alias problems
However, it does not work with submodules, which are needed for the correct aliases of preact. I guess this problem is similar to the problems with submodules using plain jspm install alias=package
described above.
$ jspm install --provider esm.sh -r react=preact/compat -r react-dom=preact/compat
Error: Unable to resolve npm:preact/compat@ to a valid version imported from file:///home/myhome/myproject/
Also note that the resolution documentation aliases react
to preact
, which is wrong according to preact alias documentation
Try the following, and let me know how far you get with this:
jspm install --provider esm.sh react=preact/compat react-dom=preact/compat -r react=npm:preact -r react-dom=npm:preact
Resolutions only behave at the package level (more like npm resolutions), that react=preact/compat
was working is really a bug - it's important that these are always package to package mappings.
So we use both techniques because you want to both lock the dependencies and also alias the entry point.
And to support all the aliases:
jspm install --provider esm.sh react/jsx-runtime=preact react-dom/test-utils=preact react=preact/compat react-dom=preact/compat -r react=npm:preact -r react-dom=npm:preact
The react/jsx-runtime=preact
is probably also a bug - in that we should require explicit aliasing of the exact install, as opposed to inferring the path into the target.
And here's an even simpler command:
jspm install --provider esm.sh react/jsx-runtime react-dom/test-utils react=react/compat react-dom=react/compat -r react=npm:preact -r react-dom=npm:preact
that
react=preact/compat
was working is really a bug - it's important that these are always package to package mappings.
This surprises me slightly. I was assuming that --resolution
could work similar to aliasing so that also subpackages could be remapped. But if the functionality is fully there also without this, I am super happy.
EDIT: Wait, I think I overlooked this. How is the package to package mapping resolving preact alias correctly? There it is a package to subpackage mapping, isn't it?
The
react/jsx-runtime=preact
is probably also a bug - in that we should require explicit aliasing of the exact install, as opposed to inferring the path into the target.
I agree. I am always expecting a plain mapping without any magic.
I tested it now, and it fails as far as I can see
running
jspm install --provider esm.sh react/jsx-runtime=preact react-dom/test-utils=preact react=preact/compat react-dom=preact/compat -r react=npm:preact -r react-dom=npm:preact
results in
imports: {
"react-dom/compat": "https://esm.sh/*preact@10.20.1/compat",
"react-dom/test-utils": "https://esm.sh/*preact@10.20.1/test-utils",
"react/compat": "https://esm.sh/*preact@10.20.1/compat",
"react/jsx-runtime": "https://esm.sh/*preact@10.20.1/jsx-runtime",
},
"scopes": {
"https://esm.sh/": {
....
"react": "https://esm.sh/*preact@10.20.1",
"react-dom": "https://esm.sh/*preact@10.20.1",
...
},
}
which on both sides is wrong - react
(the package) needs to point to preact/compat
(the subpackage)
Also I actually don't need it in the import section, as I am not importing react myself. It is really just needed within the scopes, for my case, as I want to use material-ui which by default uses react, but should use the same preact version
@guybedford can you help? I am still unable to use jspm to create dependencies which respect my preact aliases
@guybedford any progress for aliasing a package to another subpackage?
I am trying to migrate my package management to jspm importmaps, but I am failing with the react - preact aliases.
jspm alias syntax fails
Concretely, the documentation of preact recommends the following for aliases
But this fails with failures similar to
Ideally I would have imagined that simply running
jspm install react
should setup the appropriate aliases (including subfolders), by inspectingpackage.json
. This would probably be a kind of feature request.If this is not possible, or or just for now, what is a workaround?
EDIT: added below sections
Scopes do not respect aliasing
Inspecting the autogenerated importmaps, I see that there is further problem with aliasing react to preact - the scopes. There under
https://ga.jspm.io/
scope, all normal dependencies are flattened out, including thereact
dependency of in my case material ui, which of course I need to be pointed topreact
. So also here the best solution would be if jspm just takes the aliasing ofpackage.json
automatically into account, resolving dependencies respectively with aliases.EDIT: I realized that every
jspm install
with changed provider changes the scopes to its wrong version. So it is tough to fix these scopes manually, as the fixes get overwritten again.A workaround would be appreciated.
Changed Scopes in
importmap.json
are ignored duringjspm link
I just tried further and was surprised that even after correcting the central importmaps.json scopes,
jspm link
ignores it and introduces the wrong scopes (not aliased).EDIT: it actually works if you change the mapping inside the
importmap.json
scopes
(instead of only deleting the false scopes). If it is explicit,jspm
will respect it during linking.