Is it possible to use Inspector as an external js library in ES6 app?

BTW, if we consider making chunks in Webpack it seems don’t solve the problem of slow building as it can’t rebuild only changing packages. So all the packages including huge Inspector package will be rebundled again and again each bundle time. Or am I missed something?

But this is exactly the usage of chunks. Dynamic imports are the standard JS way of solving this issue.

You can’t load the inspector externally when using the es6 packages, because of the dependencies referenced in the package. So you either turn on and configure chunking in your project, or build two versions - one for debugging purposes (with the inspector), and the other without. The reason for the package size increase (I assume the numbers you have provided or not minified and not compressed) is that the inspector, being the heart of many different packages, have a LOT of dependencies from the babylon ecosystem (like GUI, gui editor, materials and so on).

Yeah, sure I understand that I can minify it without a problem, but I’m talking about the fact that bundling Inspector seriously slows down bundling speed. It’s about 1.5 seconds vs 13 seconds. Well it might looks such as not a big difference I know :grinning: but when you bundle it many times in a row it gets annoying :grinning: To be honest, I was hoping about some declaring document.window.Inspector variable that would work like a bridge that connects ES6 packages to external Inspector :grinning: but yeah, now I got it that it’s not possible to make.

Hi Lemcat,

I don’t want to be that guy who suggests changing your stack to solve problems :sweat_smile: but if bundling time is a thing for you then Vite has be made for this very specific reason.

I use Vite in all my projects and dynamic loading of the inspector is very easy to configure with chunks and still bundling time is very quick during development, I can guarantee that…

2 Likes

+1 for using Vite, it’s much faster. I haven’t ever got to a point thinking it’s slow in any project.

This is the point where you should experiment on changing your framework. Create a new branch and dedicate a day to it, it could save you lots of time overall.

1 Like

I made a small boilerplate if you want to experiment how fast Vite is, it’s a basic project with React + Typescript + BabylonJS, and it loads Inspector dynamically

1 Like

The bundling time is needed regardless if you are using static or dynamic imports.

With dynamic imports, with method suggested by RaananW, the inspector is still included into the build (dist/build folder that you upload on your server) but it doesn’t mean it is included in the main bundle (main.js/bundle.js) and so it isn’t (down)loaded when your application starts. It is included as standalone chunk and (down)loaded on demand when you dynamic import it.

I have created a repro sample that tries to explain the above concept:

It is a basic Babylon.js project that uses @babylonjs/core package with power of tree shaking. Furthermore, it loads, on demand, the @babylonjs/inspector package by dynamic imports.

Later on (and also in the build folder), you will find serveral vendor.@babylonjs....dynamic-import..js references, it is just a naming convention that i gave to the imports that are dynamically imported (to differentiate them from static imports, for instance vendor.@babylonjs.core).

Let’s dive in with the scripts:

  • npm run build, it builds the application without the inspector

    • Build time: ~5s
    • Size: ~1.3MB (main.js, runtime.js, vendor.@babylonjs.core.js)
    • When you start the application, “Inspector” button is not visible and @babylonjs/inspector package doesn’t belong to the application (never included)
  • npm run build:inspector, it builds the application with the inspector

    • Build time: ~16s
    • Size: ~11.6 MB (main.js, runtime.js, vendor.@babylonjs.core.js, vendor.@babylonjs.gui-editor.dynamic-import, vendor.@babylonjs.gui.dynamic-import, vendor.@babylonjs.inspector.dynamic-import, vendor.@babylonjs.loaders.dynamic-import, vendor.@babylonjs.materials.dynamic-import, vendor.@babylonjs.serializers.dynamic-import)
    • When you start the application, “Inspector” button is visible, the inspector packages are been included by the build phase, and only if you click on it, @babylonjs/inspector package is (down)loaded

The difference between two builds is the presence of an environment variable that tells to Webpack if you are going to use the inspector (dynamic importing it later, pressing “Inspector” button) or not (never included). Basically it is the implementation of:

or build two versions - one for debugging purposes (with the inspector), and the other without.

suggested by RaananW.


BTW, if we consider making chunks in Webpack it seems don’t solve the problem of slow building as it can’t rebuild only changing packages. So all the packages including huge Inspector package will be rebundled again and again each bundle time. Or am I missed something?

If you want to avoid to rebuild the inspector (or other modules) each time, you can consider the cache system offered by Webpack. In the repro sample there is the last script:

  • npm run build:cache, it builds the application with inspector and it relies on the Webpack cache folder (.webpack-cache, you can change the name by webpack.config.ts configuration)
    • First build time: ~16s
    • Second build time: 850ms

This way your build times will only cover files that invalidate the cache.


@RaananW, i mentioned you more than once, the tag is a must :smile:

2 Likes