For the last few months I have been working on revamping our build system. Improving, modernizing, speeding things up.
Our master branch was just updated with the changes. If you are developing using our main repository, note that you will need to clear uncommited files and run npm install to be sure you are on the right track to continue using the repository
I have started documenting most of the features. The documentation is here -
Any feedback is more than welcomed! Let me know what you think, what I forget, what isn’t working. We want it to be at perfect shape for the upcoming release!
That’s a great improvement - lots to read. react-babylonjs was switched over to workspaces and can do a lot more things locally without needing to npm link / rebuild. When I get time I will look at the dev experience for local changes - especially with running playground. Maybe with those XR controller requests that were posted today! … just need to find time somewhere LOL
Great! The server is starting much faster than before!
On Windows, I had to run npm rebuild node-sass to fix errors with SASS.
Also, when trying to run the task Run and Watch Dev Host, I get this error:
Compiled with problems:
WARNING in ./src/createScene.ts 30:4-19
export 'InjectGUIEditor' (imported as 'InjectGUIEditor') was not found in '@dev/inspector' (possible exports: Inspector)
When editing tools/devHost/src/createScene.ts, the VSCode editor also indicates it can’t find this exported method:
One question: we can’t have the playground + sandbox + node editor + … running simultaneously anymore? Each time we want to change the running package we must stop the current one and start the new one?
@sebavan had the same question. If it is important I can give them all a different port and then you can run as many as you want. But don’t forget that the node editor (for example), when integrated in the inspector, is not hosted but packaged. same for the gui editor or the inspector. so the only 2 you really need are the playground and the sandbox.
Now, the playground - if you run the local cdn server you can run playgrounds there (without the playground interface).
I know it’s not a perfect solution, and if it’s more than just seb (i am fixing nothing for this guy!) I will add the ability to change the ports for each tool individually.
@RaananW
It might be easier to serve the apps as nextjs routes than to map each to a port. Next routes will create a new html page for each route so pages are actually each an individual spa that you can even use react router in using hash or memory history. Not saying its any better, but just maybe easier for you and also will have the benefit of being deterministic (static routes instead of dynamic ports). You can even include a route in an iframe of another route, lol.
Thank you for your months of thoughtful work on the new build
Quick note to confirm build is working in a clean clone on Windows 10 / node-16.14.2 / npm-8.5.5. Massive amount of change, so kudos.
Minor notes:
A few minor doc discrepancies which I’m sure you’ll eventually update as you update and clean things. For example, I believe default for dev server is now using the TS variant of scene source, not the JS variant.
I’m using nvm-windows, and installing node-16.14.2 provides npm-8.5.0. However, I believe there is bug in recent versions of npm. The error when running npm i on a new babylon.js clone was something like ERR! Workspaces not supported for global packages. Upgrading npm to 8.5.5 resolved. Not Babylon’s problem, just maybe something to be aware of.
As an aside, the move to npm workspaces makes a lot of sense. Again, kudos. The only downside for me is that it means my personal setup of running IntelliJ IDEA on windows, and doing everything else in WSL2, will no longer work since WSL doesn’t support symlinks. Again, not Babylon’s problem. For now, I’ll either be using VS Code or just doing all babylon.js dev on the Windows side.
I could not run the visualization tests (on Windows). I get:
Running one project: visualization
jest-haste-map: Haste module naming collision: @babylonjs/gui-editor
The following files share their name; please adjust your hasteImpl:
* <rootDir>\.temp\packageES6Dev\guiEditor\package.json
* <rootDir>\.temp\packageES6\guiEditor\package.json
jest-haste-map: Haste module naming collision: @babylonjs/core
The following files share their name; please adjust your hasteImpl:
* <rootDir>\.temp\packageES6Dev\core\package.json
* <rootDir>\.temp\packageES6\core\package.json
jest-haste-map: Haste module naming collision: @babylonjs/gui
The following files share their name; please adjust your hasteImpl:
* <rootDir>\.temp\packageES6Dev\gui\package.json
* <rootDir>\.temp\packageES6\gui\package.json
jest-haste-map: Haste module naming collision: @babylonjs/inspector
The following files share their name; please adjust your hasteImpl:
* <rootDir>\.temp\packageES6Dev\inspector\package.json
* <rootDir>\.temp\packageES6\inspector\package.json
jest-haste-map: Haste module naming collision: @babylonjs/loaders
The following files share their name; please adjust your hasteImpl:
* <rootDir>\.temp\packageES6Dev\loaders\package.json
* <rootDir>\.temp\packageES6\loaders\package.json
jest-haste-map: Haste module naming collision: @babylonjs/node-editor
The following files share their name; please adjust your hasteImpl:
* <rootDir>\.temp\packageES6Dev\nodeEditor\package.json
* <rootDir>\.temp\packageES6\nodeEditor\package.json
jest-haste-map: Haste module naming collision: @babylonjs/materials
The following files share their name; please adjust your hasteImpl:
* <rootDir>\.temp\packageES6Dev\materialsLibrary\package.json
* <rootDir>\.temp\packageES6\materialsLibrary\package.json
jest-haste-map: Haste module naming collision: @babylonjs/post-processes
The following files share their name; please adjust your hasteImpl:
* <rootDir>\.temp\packageES6Dev\postProcessesLibrary\package.json
* <rootDir>\.temp\packageES6\postProcessesLibrary\package.json
jest-haste-map: Haste module naming collision: @babylonjs/serializers
The following files share their name; please adjust your hasteImpl:
* <rootDir>\.temp\packageES6Dev\serializers\package.json
* <rootDir>\.temp\packageES6\serializers\package.json
jest-haste-map: Haste module naming collision: @babylonjs/ui-controls
The following files share their name; please adjust your hasteImpl:
* <rootDir>\.temp\packageES6Dev\uiControls\package.json
* <rootDir>\.temp\packageES6\uiControls\package.json
jest-haste-map: Haste module naming collision: @babylonjs/procedural-textures
The following files share their name; please adjust your hasteImpl:
* <rootDir>\.temp\packageES6Dev\proceduralTexturesLibrary\package.json
* <rootDir>\.temp\packageES6\proceduralTexturesLibrary\package.json
jest-haste-map: Haste module naming collision: babylonjs-gltf2interface
The following files share their name; please adjust your hasteImpl:
* <rootDir>\.temp\localDevUMD\gltf2interface\package.json
* <rootDir>\packages\public\glTF2Interface\package.json
jest-haste-map: Haste module naming collision: babylonjs-viewer-assets
The following files share their name; please adjust your hasteImpl:
* <rootDir>\packages\public\babylonjs-viewer-assets\package.json
* <rootDir>\.temp\sourceES6\viewer\assets\package.json
ts-jest[config] (WARN) message TS151001: If you have issues related to imports, you should consider setting `esModuleInterop` to `true` in your TypeScript configuration file (usually `tsconfig.json`). See https://blogs.msdn.microsoft.com/typescript/2018/01/31/announcing-typescript-2-7/#easier-ecmascript-module-interoperability for more information.
FAIL visualization packages/tools/tests/test/visualization/visualization.webgl2.test.ts
â—Ź Test suite failed to run
Unable to find native addon file "D:\alexis\TombRaider\Popov72\Babylon.js\node_modules\node-libpng\node-libpng-win32-x64-102.node".
at Object.<anonymous> (node_modules/node-libpng/src/native.ts:8:11)
at Object.<anonymous> (node_modules/node-libpng/src/encode.ts:2:1)
FAIL visualization packages/tools/tests/test/visualization/visualization.webgl1.test.ts
â—Ź Test suite failed to run
Unable to find native addon file "D:\alexis\TombRaider\Popov72\Babylon.js\node_modules\node-libpng\node-libpng-win32-x64-102.node".
at Object.<anonymous> (node_modules/node-libpng/src/native.ts:8:11)
at Object.<anonymous> (node_modules/node-libpng/src/encode.ts:2:1)
FAIL visualization packages/tools/tests/test/visualization/visualization.webgpu.test.ts
â—Ź Test suite failed to run
Unable to find native addon file "D:\alexis\TombRaider\Popov72\Babylon.js\node_modules\node-libpng\node-libpng-win32-x64-102.node".
at Object.<anonymous> (node_modules/node-libpng/src/native.ts:8:11)
at Object.<anonymous> (node_modules/node-libpng/src/encode.ts:2:1)
Test Suites: 3 failed, 3 total
Tests: 0 total
Snapshots: 0 total
Time: 6.881 s
Doing npm install node-libpng failed with Error: No supported node-libpng 0.2.20 build found for node v17.7.1 on win32 (x64). It seems we can’t use node > 16 if we want to use this package (node-libpng - npm)?
@sebavan had the same issue. He switched to a different node version, which fixed it. I find it odd that nvm doesn’t support a certain node version, but…
I have node 17.7.1. I will try with a downgraded version.
[EDIT] I have installed node 16.14.2 and it’s ok now, the node-libpng can be installed. I also needed to npm install native-image-diff for the visualization tests to run (after I started the server - maybe this step could be added in the doc?).
One thing I think would be nice to have is either having the pictures of all the tests be persistent on screen or having the possibility to browse them somewhere. Indeed, it’s possible for some tests to pass as “succeeded” whereas they could be wrong, because the number of failing pixels is less than the threshold. It’s only by having a direct look to the pictures that we can detect such failing tests.
To be clear, the error comes from certain npm versions, not node. As I’m sure you know, in linux world, node and npm are versioned separately. In windows world, it’s complicated. For whatever reason, nvm-windows didn’t install the latest npm patch version, so I had to upgrade it manually to avoid that error (independent of node and nvm-windows) . Different node versions installed with nvm-windows will include different npm version by default, so this probably a temporary problem that will affect a small number of people. I would link here to help anyone else that comes across this, but there is no one way to upgrade npm on windows that just works for everyone. This SO should help though.
There is really no need for that. it works well locally and on the CI, and this is the first time I hear about this. would be great to know why exactly it happened, but that’s not needed.
You can reduce the threshold and get the error report. Since I am actually capturing the browser screen I can’t show the original image.
Test suite failed to run
Unable to find native addon file "D:\alexis\TombRaider\Popov72\Babylon.js\node_modules\node-libpng\node-libpng-win32-x64-102.node".
but instead of node-libpng it was quoting native-image-diff. After I installed native-image-diff this error disappeared and the visualization test script did work. Maybe it’s node-libpng that needs it on Windows?
The problem is that a test that you setup at some time with a given threshold could “fail” later on because of some changes you did (or someone else) but still be below the threshold (so, from the point of view of the script the test did not fail, that’s why I haved added the quotes). It already happened to me and you can detect these problems only by scanning the output pictures yourself from time to time and not trust that because the tests passed everything is ok.
Is it not possible to generate a .html file somewhere with the output+model pictures, much like what we had previously?
I don’t really understand this one, you must have the output + model pictures as you need to perform a diff between both? I think we don’t need to have them displayed on screen at the time the tests are run, being able to access them afterward should be enough.
Great! I do not run the framework builder often (sub-classing is more my thing). I do have a bunch of .map files & one change to the performance monitor graph class to write on a texture.
Will just set the class file aside, ditch the maps (changes), update & put the class back. For 1 class, crude but effective seems like a got way to go. Will wait for the final 5.0, bookmarked for now.
That’s the way it is configured. You will have failed test results and an HTML file that will allow you to compare the two results. It is also uploaded when the CI fails. The directory is called jest-screenshot-report
LOL
