I think the best fix would be to move to a module structure under babylonjs that is similar to lodash. Importantly, no existing client code would break as it is. As in, you import from babylonjs and you get everything currently exposed in the root babylonjs/babylon.js file – that would remain unchanged.
The strategy is basically put everything in a single folder, but dont export subfolders from the root index.js except the core. This allows you to add as much code as you want to the project without inflating the default export at all. So for example, you would import from babylon/materials and get what is currently @babylon/materials aka babylon-materials, just like you can now import from lodash/merge and only get merge.
This has an additional benefit of unifying everything under the single babylonjs package going forward. Organizing this is a bit tricky given that you guys are currently publishing under 2 namespaces. To start, I would make an announcement that all the @babylonjs/submodules should be considered private apis and babylon-submodules deprecated. The babylon-submodules would still need to published for backwards compatibility of client imports. Ideally, the babylonjs-submodules will be published as single-line re-exports of the @babylonjs/submodules. This is ideal because it would eliminate copies of bundles when third party plugins or even a lot of the internal tooling inside the babylon repo exports the same thing from different root namespaces. For a real world example, this would fix the problem of using babylonjs with react-babylonjs, which uses @babylonjs/core.
There are a few options from a developer ergonomics standpoint here, as in , the dx of actually working on the babylon codebase. Lets use the practical question of, where would the @babylon/core code live? Either in a @babylon/core package or in the babylonjs/core folder (basically how it is now). The babylon/core is the better option to develop with, by far. If you switch to lerna for developing, you’re only making maintenance harder, not easier in any way. My advice is to use lerna as a publishing tool, not an installation tool. Keep all of your dependencies in a single package.json file at the root, there’s truly no need to make it harder on yourself. Also, for an example of how to just use a nested node_modules instead of lerna, see the pouchdb repo GitHub - pouchdb/pouchdb: - PouchDB is a pocket-sized database.. Or, here is a very simple example using typescript’s build system .GitHub - jeremy-coleman/simple-ts-cra-monorepoish . If you’re really stuck on lerna though, the pixi monorepo is very well structured and has a similar strategy of internal @pixi/submodule development while hoisting everything to a bundle package. Additionally, arrow/js at master · apache/arrow · GitHub is a good example of single repo to multi-repo publishing using lerna/gulp. I can help set up a poc or even a variant of each.
Btw, this setup would allow you to trivially add variant builds to the babylonjs folder, for example, adding babylonjs/wgpu , babylonjs/webgl , and babylonjs/webgl2 folders that only re-export the minimally required stuff for each and apply any necessary revisions aka patching webgpu matrix math. You wouldnt need to and shouldn’t bundle this or publish this separately from babylonjs.
ignore this, just notes for me
.Vue + babylonjs experiment - #10 by jeremy-coleman