Preact: Continue publishing preact/compat as standalone node module also?

[maranomynet]

I'd like to suggest you continue publishing the npm package preact-compat as alternative method of installing/using preact/compat.

This would make it possible to use npm and yarn's native package.json dependency renaming syntax and skip installing 3rd party aliasing-plugins and/or relying on bundler config tricks.

Like so...

npm install react@npm:preact-compat@^10 react-dom@npm:preact-compat@^10

resulting in these depdendency lines in package.json

    "react": "npm:preact-compat@^10",
    "react-dom": "npm:preact-compat@^10",

The only thing that might make this unfeasible, is if this would result in large amounts of code being imported twice - once from node_modules/react and then again from node_modules/react-dom.
I'm not familiar enough with the preact codebase to judge how tight the coupling is between the "react"y and "react-dom"y bits of Preact.

[sventschui]

Not super familiar with the dependency renaming but if it results in two copies of preact-compat being located at node_modules/react and node_modules/react-dom (I think this is what your last paragraph mentions) then this doesn't work in terms of simply shipping the preact/compat folder as a separate npm package as we will be shipping the compat code twice and it has side effects.

What might work tough is to publish a preact-compat that is a single file doing module.exports = require('preact/compat') as this would be de-duplicated later.

One thing that needs to be mentioned tough is that if one of your bundles uses an incompatible version range of react (note all "regular" react versions will be incompatible) then it will result in installing react to node_modules/fancy-react-library/node_modules/react. Again here I'm only 90% sure this is the case as I did not try this out.

If you want to give it a try you could experiment with different cases (fully blown preact-compat, simple re-export, ...) using "react": "file:.../local-preact-compat".

[cristianbote]

Unfortunately installing a package like that npm install react@npm:preact-compat@^10 react-dom@npm:preact-compat@^10 ends up with preact being duplicated(basically drop-in replacement) of both, react and react-dom.

So I don't see how this would work. What do you think @maranomynet?

[ForsakenHarmony]

does that cause it to resolve dependencies in a non flattened tree? Otherwise you could just have a tiny wrapper that imports preact

[andrewiggins]

Does npm aliases work for compat? At least when they were first introduced, it only aliased the package for yourself, not for any libraries you add (e.g. when your code imported react you would get preact-compat but if you used react-router, it's react import would still be react, not compat). That's my understanding of the relevant section in the RFC (see the paragraph about problems this RFC does not address). Has npm changed the behavior of aliases since this RFC was released?

[jeremy-coleman]

I think it depends on how the sub package defines its dependencies. For ex if react router were to have react as a peer dep, the npm alias should work, but an exact dep would cause a nested node_modules folder. Lerna hoist and postinstall scripts can fix anything tho if u really need to get something working. To ensure no dupes, I suppose postinstall react and react dom folders with an index.js pointing to preact would do the trick. Lerna hoist will fix the nested package resolving, but cant use that with yarn. Lerna hoist with npm is way faster though anway these days, at least on windows