It errors on a function called “webpackUniversalModuleDefinition”. The variable “exports” evaluates to undefined, which causes the else condition to try to get Babylon features from root[“BABYLON”] which, because I’m using ES6 modules, the root variable BABYLON doesn’t exist.
Am I missing something, or is webpack just required for this to function?
The package.json for @babylon/inspector lists 4.0.3. I just went through some of the other non-core packages, and the inspector seems to be the only one bundled. It gives a Typescript file and a bundled one (babylon.inspector.bundle.max.js). All of the other packages contain the Typescript source, and a non-bundled ES6 module JS output
Yes, the build process of the inspector is using webpack to pack the es6 module.
I’ll check with the team internally why, there must be a good reason for that. Will keep you updated here
Thanks! And if that’s just the way things are, I’d love to hear about any thoughts on working around it. I know when I’ve asked about modules previously, your team says they are using something like es-dev-server internally, so I imagine it might be a problem you’ve had internally as well
The inspector ES6 version is still built using webpack and is, in general, UMD-enabled.
I ran a few experiments and it seems like we will need to make a few (small) modifications in the code and change the build process (and the declared dependencies) to fix that.
You should be able to insert it in a normal script tag in your page as long as you rely on the es6 bundled version. This is actually what we do when developing locally.
Yeah, unfortunately, I’m kinda curmudgeonly in regards to bundling during dev. I’m using straight up ES6 modules when I’m building something, and this is when the inspector matters to me the most. I’d honestly rather wait for 4.2 rather than changing my process to accommodate. Thanks tho!
Oh, huh - for some reason I got the impression that you couldn’t mix non-bundled Babylon with the bundled inspector, so I didn’t even try. I’d have assumed that since the BABYLON window var didn’t exist, it wouldn’t work out for the inspector. Guess I need to give it a shot!
Using TS + Babylon.js ES6 modules, including inspector ES6 module only for local dev and automatically excluded from production builds via webpack string replace loader.
Hey Brian! Looks great! And, hehe, my question comes from a similar place. I TOO HAVE A STARTER KIT Mine is pure JS and needs no front end building/bundling. Yours, again looks great - but if you’re using TS and Webpack, doesn’t really help my use case (at least in terms of what I understand). Thanks for chiming in, though!
But inspector is importing the whole core as it inspects almost everything. The best solution is to code split and side load it to create a main run bundle really tiny and a second debug one not always loaded containing all the required inspector dependencies. This is exactly what I am doing in this project : BabylonjsInkSample/src/debug at master · sebavan/BabylonjsInkSample · GitHub
Mine is pure JS and needs no front end building/bundling. Yours, again looks great - but if you’re using TS and Webpack, doesn’t really help my use case (at least in terms of what I understand). Thanks for chiming in, though!