How to alias react to preact consistently?

[schlichtanders]

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

jspm install react=preact/compat react-dom/test-utils=preact/test-utils react-dom=preact/compat react/jsx-runtime=preact/jsx-runtime

But this fails with failures similar to

Error: No './jsx-runtime/jsx-runtime' exports subpath defined in https://ga.jspm.io/npm:preact@10.20.0/ resolving react/jsx-runtime/jsx-runtime imported from file:///home/myhome/myproject/.

Ideally I would have imagined that simply running jspm install react should setup the appropriate aliases (including subfolders), by inspecting package.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 the react dependency of in my case material ui, which of course I need to be pointed to preact.
So also here the best solution would be if jspm just takes the aliasing of package.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 during jspm 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.

[schlichtanders]

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

[guybedford]

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.

[guybedford]

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.

[guybedford]

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

[schlichtanders]

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.

[schlichtanders]

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)

[schlichtanders]

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

[schlichtanders]

@guybedford can you help? I am still unable to use jspm to create dependencies which respect my preact aliases

[schlichtanders]

@guybedford any progress for aliasing a package to another subpackage?