Breaking change

I just want to report a breaking change from upstream perspective for visibility.

Renaming files I think was agreed as a breaking change. I don’t know if I should create that file and export the same stuff or leave it, but then I will need to generate a new build of react-babylonjs. I know and do appreciate how important refactoring and cleanup are - and also the downside of cluttering for backwards compatibility. I have an open issue that react-babylonjs doesn’t work with @latest, since I am importing from the file that was renamed (essentially deleted depending on how you look at it). react-babylonjs is built with babylon as a peer dep. I can see how renaming files may not seem to some as a breaking change, since nothing breaks in the main libraries!

Fix view support in WebGPU · BabylonJS/Babylon.js@8b65e71 (

1 Like

@sebavan, @Deltakosh, @RaananW - I imagine this is something one or all of you have thought about in the past and have some perspective on. If BJS consumers import a specific file path, and then we move a file, their import is broken. Do we consider the file structure to be part of the public API? I assume there are cases where it must be because we don’t export it all the way up to index for tree shaking reasons?

1 Like

Renaming files is considered a breaking change. We don’t do that lightly, and we try to avoid it as much as possible. If it’s unavoidable, we do our best to provide a sort of redirect to the new file. In this case, it would be quite simply an export call:

// engine.views.ts

// ES6 Backwards compatibility - file has moved
export * from "./abstractEngine.views.ts";

If you want to test this solution and submit a PR to add it back, I will be happy to approve it

1 Like

Thanks @RaananW I’ll add a PR tonight. Cheers.


Just want to add that the team is doing a really fantastic job on backwards compat. The move to 7.0 and onwards has been pretty seamless.

Babylon.js/ at master · BabylonJS/Babylon.js (

Also @RaananW while following linking instructions ^^ I think I came across some missing updates to docs.

$ npx nx build core 
 NX   Cannot find project 'core'

# should be?
$ npx nx build @babylonjs/core 
   ⠸  Nx is waiting on 2 dependent project tasks before runn

Additionally, the referenced prepublishOnly script is missing. The build script above for me was sufficient for linking purposes. I would have updated the docs, but maybe there is a faster build.

Lastly I did hit a couple of other back-compate build issues with AbstractEngine - probably they are known and documented. Specifically the callback on onContextLostObservable.add(...) and scene.getEngine() type errors. They were pretty easy to fix - the changes look good though to further separate WebGPUEngine.

Cheers: compat: Add redirect for moved file by brianzinn · Pull Request #15154 · BabylonJS/Babylon.js (


oh, this file should be removed! i was sure i did it already. the updated document is in the doc page:

Start Contributing to Babylon.js | Babylon.js Documentation (

1 Like

The md is still there in the main repo, do you want me to delete it ?

Gone with the wind…

1 Like