I get the below error when running “npm install”. NPM version is 8.5.0 and node version is 16.14.2 and Mac OS is up-to-date.
Error: No supported node-libpng 0.2.20 build found for node v16.14.2 on darwin (arm64).
1 Like
thanks!
I am actually just about to test on a mac. I will update here!
1 Like
One mac issue was just resolved. I couldn’t reproduce this one, but I assume this is because you are using an M1 mac (and not intel-based). Am I right to assume that?
libpng does statee they support osx on node 16 (GitHub - Prior99/node-libpng: Unofficial bindings for node to libpng.), but the don’t say what processor. There is an open issue - Cannot find normal binary files on the MAC of Apple m1 chip · Issue #45 · Prior99/node-libpng · GitHub, and it seems to be opened for quite some time. Does this prevent you from using the repository altogether (i.e. - you can’t run npm install at all)? I can try making jest-screenshot (which is the dependency requiring it) optional, as it is only used for visual testing.
Yep I’m using a new M1 mac. The install fails without installing the build-tools so I can’t build and use the repo so far. Skipping jest-screenshot sounds good for now thou… Thanks for looking into it. 
npm run build:dev
Output:
sh: build-tools: command not found
1 Like
i’ll make that optional! I hope it’s the only one.
And yes, the build tools will not be built if install fails, and then it won’t work… i’ll submit a PR in a sec
It’ll be merged soon, will be great to know if it works after that
2 Likes
Okay I also had to make “canvas” an optionalDependency in the main package.json file and now it’s working. I think that one doesn’t support M1 yet either (install was failing to find a package to download for it, causing the install to fail still). Thanks!
i’ll add that to the optional as well! “canvas”? that’s the name of the package? I don’t remember adding it directly, must be a dependency of a dependency it’s right there at the root. i’ll take it out as well.
Awesome, I just checked a fresh clone of the repo and is working now, thanks again. PS the build process is MUCH faster now! 
1 Like
I have not looked this in detail, I only recently started playing with babylon. Does this new build system allow easier creation of smaller bundles (when only subset of features are needed).
The ES6 @babylonjs modules allow tree shaking. There are some threads on how to bundle via build, but best to let bundler prune automatically based on your application, if you can.
Thanks for the hint !
The codebase is huge. Is the es6 module support new and came with changes mentioned in the topic of this post ?
As mentioned before, I am new to babylonjs and not aware of many things about the project.
if I can use it as ES6 module with treeshaking like you said then I have no need for a special process of building a smaller bundle, I can let bundler base it on my imports.
1 Like
It’s not new - check out the docs are here for more details 
Babylon.js ES6 support with Tree Shaking | Babylon.js Documentation (babylonjs.com)
1 Like
I think I’m a bit lost with the new GIT repository.
Did I understand correctly: Now each update 5.0.1, 5.0.2, 5.0.3 … Are in a Zip file to download that you have to look for in Tag?
https://github.com/BabylonJS/Babylon.js/tags
Before I used TortoiseSVN to update the repository on my PC, then I used a PHP script which once executed updated all my projects in one click.
Now I have to download a zip and go look for all the files one by one. which is longer.
My question is where do the updated JS files go (where are they built now?)
When I look in preview release, they are no longer updated :
https://github.com/BabylonJS/Babylon.js/tree/master/legacy/dist/preview%20release
The version is rc.4 which is not 5.0.3
Please help me understand what I missed. Thanks
PS: When I download the 5.0.3 zip file, it’s still in the 5.0.0-rc4 console. This makes me even more confused. it’s ok with : https://preview.babylonjs.com/babylon.js (5.0.3) I would like to be able to have the file locally (if it is still possible)
There is a .gitignore in the ./, which has dist. My guess is that it is intentional to not have the dist output under source control.
A couple of potential options to get available locally:
- write a script using curl or wget to download from CDN?
- update git repository and then build with
npm run build:umdthen you will see your files in ie:./public/umd/babylonjs/dist. You can follow other paths for remaining needed files.- babylon.js
- babylon.js.map
- babylon.max.js
- babylon.max.js.map
- babylon.module.d.ts
I think the entire ./legacy is uneeded currently and can be disregarded, but should let Raanan confirm that and likely he has a better way!
1 Like
Yep, legacy should be disregarded and is only there too slowly port everything, as there is still a todo list.
If you want the files locally you can either build it yourself, download from the cdn or use npm to download the latest package. These are the ways to get the files locally. The cleanest way was suggested by @brianzinn - run “npm run build:umd”. If you want it all in one directory you can run “npm run prepare-snapshot” to create the cdn structure locally in the .snapshot directory.
I can gladly try to automate the release creation. In fact i have already added the task yesterday, but it hasn’t been tested fully. What we won’t do is continue updating our git repository with daily changed in production code (both minified or not). It bloats the repository for no reason and doesn’t scale.
I don’t know how to use npm unfortunately.
I understand that it is easier for developers to have made all the changes in the repository, but it may complicate things for users if they now have to build the files for local use.
I prefer having the files locally because it’s faster to load than using url.
I don’t understand what the said file is for if it is no longer updated. Is this only for the official release?
As for the version error that I explain in bold in my post. is this a bug? The cdn version is 5.0.3, but when you download the 5.0.3 zip, the local files are 5.0.0-rc.4.
I have to say that the change in the repository has some upsides, but there’s also a step back from before for users who like to update patches regularly.