So we upgraded to 9.8.0 and have been having some problems with running a development build since the upgrade. Something with the barrel imports seems to be making some circular references and the build is dropping this error:
We can do a production build just fine, so I’m not sure what’s going on.
I also saw this git issue:
But its unanswered as well. What should I be looking into to try to troubleshoot this?
Adding more info:
We can build successfully from 9.6.2, and, holding all other things constant, it’s the upgrade to 9.8.0 that causes the break for us.
The major repo restructure from Tree-shaking - the pure barrel by RaananW · Pull Request #18441 · BabylonJS/Babylon.js · GitHub jumps out as a suspect.
let’s solve this. can you share more of the build logs? a specific issue I can track?
That is the only thing that drops as an error in the build. Other than that its just vite warnings about static and dynamically imported assets which is not causing this.
Trying to gather more information for you now. Im starting to think its something with our source maps.
the pure barrel was introduced, and files involving side effects have changed in architecture, but it should have continued working as is. I tested many different scenes making sure, but of course not saying i missed nothing. It would be great if we can debug this so I can know if it is something i can fix on our end, or it is something you can fix in your environment.
Yeah me and @Will_FrameVR are digging on this now, its for sure something with the source maps. Ill get you more info as we discover it. I appreciate you <3
Ok so, it seems to only happen on “inline” sourcemaps. I asked Opus about it and this is what it had to say:
```
That choice was fine before Babylon 9.8.0 — but the tree-shaking PR exploded effective chunk sizes (you can see it in the [vite:reporter] warnings above the crash: ShadowGenerator.js alone is now both statically and dynamically imported from inspector, cascadedShadowGenerator, index.js, FrameGraph, goKartsManager, etc., so Rollup merges huge graphs together). Larger chunks + inline maps = the mapFileCommentRegex in convert-source-map finally hits its catastrophic-backtracking ceiling.
```
Im not to confident about this though because on our git CI it fails even with source maps false.
well, opus is usually a smart fella 
I will run some tests tomorrow and see. i assume this is dev only?
yes sir
Did some digging. I couldn’t find any issue with circular dependencies (which i was afraid off when you showed the error). The new pure barrel implementation introduced roughly 700 new files in the repo. So:
This is the only issue i could find with the new implementation. I assume you are not importing from the root index, but you are probably loading from some index barrels within the directory structure? The extra files might put some load on the number of inline sourcemaps added to each chunk.
Doing this:
import { Engine, Scene, Vector3, FreeCamera, HemisphericLight, MeshBuilder } from “@babylonjs/core”;
Will result in chunk around 35 MB, with about 21.5 MB of that being inline sourcemap. That’s a lot . But it is also expected.
So then I must have been mistaken about the causality being the source maps, thank you for looking into that. I’m going to a build on a prior version and then this version that we are struggling with and monitor the resources to see if I cant figure out more for us. There is definitely something here just not sure what yet. Thank you so much for trying to help us figure this out.
Its starting to look like its Vites fault. Ran a test with v8 and things seem to be working smooth!
So we don’t have a good answer on the root cause,
We looked at max memory usage during build and found no difference
We looked at total build size and found a only slight increase (3%) with Babylon 9.8
Maybe that one extra layer of import added to all our Babylon imports was just a straw that broke the camel’s back. Vite 8 ships a new bundler written in rust so its no surprise that would improve efficiency enough to get us across the line if that’s the case.
Will be really great if I could convince you to give the new pure barrel a try! It will provide you with the smallest package size and only involve registering aside effects using the Register functions.
Will also clean up your code and make things a little more structured
so here’s what’s holding us back:
@babylonjs/core/pure, which would be more appealing as we could simplify all Babylon imports and eslint enforcement