react-three-fiber
react-three-fiber copied to clipboard
pmndrs
react-three-fibers depends on `react@18` and a version of `zustand` that disallows `react@18`
Package.json for module "@react-three/fiber" has dependencies:
"zustand": "^3.7.1",
"react": ">=18.0",
Zustand package.json for versions ^3.7.1 has dependencies:
"react": "^17.0.2",
This is impossible to satisfy without loading two versions React. That would create two contexts and cause react-three-fiber to crash. The resolution would be to break the dependency requirements wish some module resolvers (bundlers or esm resolvers) would not allow.
Suggestion:
Consider zustand to accept "react": ">=17.0.2 <19.0.0"
where do you see a hard dependency in zustand? https://unpkg.com/browse/[email protected]/package.json
i only see peer:
"peerDependencies": {
--
71 | "react": ">=16.8"
72 | },
The problem is at lines 168-169. Although 18.0.0 satisfies ">=16.8", it will be limited by "^17.0.2" in the devDependencies when resolving in a dev context.
168: "react": "^17.0.2",
169: "react-dom": "^17.0.2",
I.e. "^17.0.2" and ">=16.8" yields "17.x.x".
It could be argued that the devDependency should not matter in most cases, but it broke the cdn development distribution of @react-three/fiber at esm.sh and there is problably no reason not to have the peer dependency and developer dependency aligned. I will report the problem to them (they use esbuild). They provide development distributions so maybe it works for production. However, I think the problem should be fixed at both ends.
In addition to Zustand, there was also a version 17 upper limit on React in react-use-measure in its developer dependencies. I provided pull requests for both repos.
Hmm, I wonder if there's a better solution on developer end. Changing devDependencies doesn't make sense. (For example, 16.8 is supported.)
@dai-shi I agree. Not a problem. Just change it to ">=16.8". That would do the trick. The essential part is that it does not make sense why the developer context should be capped at 17 while the distribution context is not.
Anyhow and reqardless, esbuild/esm based builds fails at runtime when using hooks due to the inclusion of both React versions in bundles.
It could be argued that the devDependency should not matter in most cases, but it broke the cdn development distribution of @react-three/fiber at esm.sh and there is problably no reason not to have the peer dependency and developer dependency aligned. I will report the problem to them (they use esbuild). They provide development distributions so maybe it works for production. However, I think the problem should be fixed at both ends.
I have no problem resolving this here but this is pretty clearly an issue with esm.sh (from IMO a poor design decision). I would prefer to resolve this over there rather than go through the entire ecosystem.
This looks to be resolved upstream at https://github.com/ije/esm.sh/issues/296, but do update if this is not the case.