When I start a project, I do not download files off of Github but maintain my external dependencies through npm. However, many extensions are not referenced on npm even though this is how I installed @babylonjs/core and @babylonjs/loaders. I have searched for a while and I can’t find such list of extensions. Honestly, npm sucks when searching modules so I wonder why this project doesn’t have such references?
Reading through the extension page, here, I find no useful way to import any module into my project and start experimenting with it. In fact, most examples do not have a complete working setup, just partial snippets. I guess I could sniff through the code, of course, but why making such a detour?
Yeah, I’ve seen those pages and, as I have implied, I have started to play with BabyloneJS that way. But where are all the extensions? They are referenced in the repository and official documentation, etc. Why aren’t they on npm as well?
I’d imagine because they are “extensions” in every sense of that word i.e. third parties created them and they’re not developed or maintained by the core team. It would be up to the individual extension developers to create and maintain npm packages.
Although, and I’m contradicting myself a bit here, I know SkyMaterial is available in the materials package (@babylonjs/materials) and BabylonViewer is available via @babylonjs/viewer. Both of these extensions are listed on the NPM page.
As far as I’m concerned, if they are included in the official repository, they should at the very least be part of the namespace and maintained, or be part of some incubator packages (like how Material UI does it with it’s lab npm package). Those submitting extensions should show that their projects have maintainers before it is added to the incubator. Other projects have similar policies, where issuers are encouraged to submit PRs on their own, then it is only a matter of reviewing the PRs and merging.
So, the projects are already in the repository! This is not changing much if not that they are available on npm! The rest is simply a matter of community guidelines and common efforts. Honestly, if I don’t have an npm module, I’m not really inclined to contribute, because it feels like the community does not care about the extension.
Maybe take some time to understand a community before passing judgement. I’m not a core maintainer, just a community member myself, but there are likely very good reasons why things are the way they are, not the least of which is that people only have so much time and need to prioritise efforts.
As I mentioned, many of the extensions listed in the docs are included in the npm packages. Others, like Caster GUI for instance, are unmaintained and superseded by Babylon GUI which again, does have an npm package. So that’s just one solid example of why something wouldn’t have an npm package.
Most of what’s listed on the docs extensions page is in one of those packages e.g. materials in @babylonjs/materials and procedural textures in @babylonjs/procedural-textures
There are exceptions, like Caster GUI (which represents the bulk of line items on that extensions page), but I’ve explained that.
@PirateJC is working on the doc to help ensuring this is more understable what is where but in a nutshell we support and maintain everything aside the extenstions (community contribs) / editor (@julien-moreau ) / blender exporter (@JCPalmer ) and Unity Exporter (@MackeyK24 )
This is amazing to group them under the same org to simplify management and the doc should outline it.
Also note that all the extensions are not meant to be NPM released and if they are, there individual readme and package.json probably helps finding where they are deployed.
