While yes I can see in the inspector types that it makes use of the react types, the issue is that in doing so, it pollutes the global JSX namespace with the react versions of JSX types, which for me (using inferno) causes type errors in any tsx/jsx file. These types can’t be ignored (tsconfig excludes don’t work for types, and the types array doesn’t stop another package (i.e. the inspector) pulling in the types), so the only way I can see for me to fix it in my project is to patch the Inspector type definitions. What is the use case for the inspector needing to expose the react components to users anyway? Could the react types be moved to optional dependencies if it’s determined such a use case exists.
Regarding the other peer dependencies, again I don’t see the use case for mixing versions, as this inevitably leads to errors due to functions/classes etc changing (indeed I assume this was the issue that prompted this thread in the first case). Babylon.js is developed such that all these packages are updated at the same time anyway, so why not just use absolute versions, and have them listed in dependencies? As it stands, yes I can just manually add all the needed peer dependencies to my own package.json, but this seems like a lot of clutter, especially for what I imagine is the most common use case of wanting @babylonjs/core and @babylonjs/inspector installed.
What’s worse though, is that even npm doesn’t work (with automatically installing peer dependencies), with the way peer dependencies are used in all the @babylonjs packages, unless using the most up to date version (of babylonjs). Old versions of babylonjs combined with the same version of the inspector cannot be installed, unless all the peer dependencies are specified (with the same version) in your package.json.
e.g. a project with this package.json
{
"name": "npmtest",
"version": "1.0.0",
"description": "",
"main": "index.js",
"dependencies": {
"@babylonjs/core": "5.15.0",
"@babylonjs/inspector": "5.15.0"
}
}
Gets this output from running npm i
npm ERR! While resolving: npmtest@1.0.0
npm ERR! Found: @babylonjs/core@5.15.0
npm ERR! node_modules/@babylonjs/core
npm ERR! @babylonjs/core@"5.15.0" from the root project
npm ERR! peer @babylonjs/core@"^5.0.0" from @babylonjs/inspector@5.15.0
npm ERR! node_modules/@babylonjs/inspector
npm ERR! @babylonjs/inspector@"5.15.0" from the root project
npm ERR!
npm ERR! Could not resolve dependency:
npm ERR! peer @babylonjs/core@"^5.22.0" from @babylonjs/gui@5.23.0
npm ERR! node_modules/@babylonjs/gui
npm ERR! peer @babylonjs/gui@"^5.0.0" from @babylonjs/inspector@5.15.0
npm ERR! node_modules/@babylonjs/inspector
npm ERR! @babylonjs/inspector@"5.15.0" from the root project
npm ERR!
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force, or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.
I really think that just putting everything in dependencies, with a fixed version, and telling users that all @babylonjs packages included in a projects package.json should be the same version, would be the simplest and clearest way to solve this (and this threads original) issue.
Peer dependencies should only really be used if you expect the user to already have those dependencies installed (and specified in their package.json), which in this case, should probably only be @babylonjs/core. (The react types especially fall foul of this, and would ideally be in dependencies, if that didn’t cause issues due to global types).
