How to alias react to preact consistently?

[schlichtanders]

How to alias react to preact consistently?

[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]

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 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]

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

[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/*[email protected]/compat",
    "react-dom/test-utils": "https://esm.sh/*[email protected]/test-utils",
    "react/compat": "https://esm.sh/*[email protected]/compat",
    "react/jsx-runtime": "https://esm.sh/*[email protected]/jsx-runtime",
},
"scopes": {
    "https://esm.sh/": {
        ....
        "react": "https://esm.sh/*[email protected]",
        "react-dom": "https://esm.sh/*[email protected]",
        ...
    },
}

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?