NextJS + BabylonJS (ESM) crash

Hi everyone,

I’m trying to use NextJS + BabylonJS on their latest versions.

There are a few topics on this already: How to use Babylon with Next JS and Babylon + Next.js Setup Optimized for SEO, Load Speed & Developer Experience but all of these use older versions of NextJS (pre v12).

The main difference is that in the previous versions of NextJS, the @babylonjs modules needed to be traspiled to be included in the build, but starting with NextJS v12 that is not necessary anymore (Blog - Next.js 12 | Next.js).

I’ve put together a small sandbox (babylonjs-nextjs - CodeSandbox) showcasing the error trying to use the latest @babylonjs packages, and my best guess is that it might have something to do with the latest ESM work and the distributable shape of BJS?

The error looks like the above, and the best guess is that the ? operator doesn’t exist in the current JS runtime?

My local setup is quite different, but it ends up in the same error. I’m using TypeScript as well, and when targetting ES5 the main project runs well, but when trying to run the project in Cypress (same ES5 target) - I get the error above. Replicating my setup is too difficult to do in a sandbox environment, but it essentially throws the same error.

I’ve tried in the past (pre v12 NextJS) with transpiling the @babylonjs packages, as well as using the babylonjs packages, and they were successful attempts. The only difference was that the babylonjs packages were pretty much impossible to debug in the browser.

Any idea what we might be able to try to make this sandbox work?

Many thanks!

cc @RaananW

i assume internally it is using webpack 4? do you have babel included in your compilation pipeline?
NextJS, if i remember correctly, has the ability to use webpack 5 instead of 4. will it be possible for you to try that?

It seems NextJS uses Webpack 5 for compilation by default starting with v11 (webpack5 | Next.js). Starting with v12 NJS also uses the SWC compiler by default, Advanced Features: Next.js Compiler | Next.js.

As for Babel, it’s not included in my build pipeline at all, the sandbox is quite simply just bootstrapping NextJS and adding (and importing) BJS. Nothing other than that afaik.

Hey @Andi,

The error you’re getting it’s undoubtedly pointing that the parser can’t understand the optional chaining feature of the JavaScript.
I’ve found something like that on the Internet:

As the error you’re getting is coming from the node_modules I think you might try check that solution.

I think the move away from ES5 is causing this issue… does that mean I have to start transpiling the BJS distributable now to fix these kind of issues?

1 Like

you need to understand which one of the tools you are using does not accept the newer syntax. it is usually webpack 4, as webpack 5 supports this syntax without an issue.
You can add a pre-step to your js files and transpile them using babel.

Oh, apparently upgrading to the latest BJS (5.27.1) seems to have fixed the issue. The link to the sandbox runs OK, as well as my local testing setup with Cypress.

Not sure exactly what the issue might have been, and my skills in the JS build system are not great to be able to properly troubleshoot it. Thanks for the input.


Hi @RaananW, I’ve got an older setup as well using Webpack and Aurelia, it worked fine until 5.19 but updating to 5.28 seems to create this error.

Doing a bit of investigation, I see this PR was the one that made my previous scenario work (Set target to ES2018 by RaananW · Pull Request #13086 · BabylonJS/Babylon.js · GitHub) but as part of this PR I see that the @babylonjs/inspector package did not get the same es2018 target (Babylon.js/ at master · BabylonJS/Babylon.js · GitHub).

Is there a chance to apply this change to the inspector as well or maybe there’s a different reason for why it was being left out?

Thanks in advance.

PS: I would like to avoid as much as possible including babel transpiling over node_modules, my lack of experience here would make me lose a lot of time.

sure, I can make them es2018 as well i’ll submit the PR later today

1 Like

Hey @RaananW, can you say something more why do we go back to 2018 from 2021 with the target?

good question!
We had a few partners and community members that asked to lower the target for the time being until they fix their build systems and support a more modern syntax. I often push for modern code and will continue doing that as much as I can, but we also need to accept the fact that production users that suddenly can’t upgrade without making changes will decrease the satisfaction from the framework and maybe the usage as well.
I am still pushing towards es2021 (and even es2022) in future versions. I am in great hopes that the js ecosystem will eventually stabilize and will be able to provide updates to the build tools more often. And that the browsers will also move faster to adopt new standards. It’s a cat-and-mouse race.

And, of course, es2018 is 10000x better than es5 target :slight_smile: so we are on the right track.

1 Like

Thanks for sharing :slight_smile:
Have you set any deadline for the partners for the updating their projects, eg. end of the year? It would be nice to have some kind of a roadmap, even if it can change over time.

Babylon 6.0 will be released in ca. 6 months, and together with it we are planning to have a new esm-friendly package that will target es2021/ES2022.

1 Like

That’s great news! Do you have list of key features coming with the v6?

Everything can be found on github:

Issues · BabylonJS/Babylon.js ( (filtered to v.6.0)

1 Like

I’m having another interesting moment here - basically trying to integrate the BJS and Jest into the project for unit tests.

With the ESM model, basically everyone that uses BJS need to transpile the lib (to some extent), and in doing so I ended up with this sort of runtime.


The Jest config does contain the transpiling config to be able to properly handle the JS files in the node modules.

transformIgnorePatterns: [“/node_modules/(?!(@babylonjs)/)”],

As you can imagine, having to wait minutes to run unit tests is an absolute productivity killer. I’m also looking into using swc/jest instead of ts-jest but the current defaults point to this setup.

Since as you mentioned, BJS moves fastly to the newer ES versions, what about coping with our build pipelines? Would there make any sense to keep distributing it as ES5 still until the ecosystem stabilizes first?

(the following is my personal opinion :wink: )

There are many ways to solve this. Asking the framework you are using to target es5 instead of a modern target is not one of them.

ES5 is technically ES2009. We are 14 (!!!) years away. If the tools you are using still require you to use a 14-year-old technology there is something wrong with the tool. ES2018 is, well, 4 years old. I would consider that stable.
TBH - we are running unit tests, and I have never waited more than a few seconds for everything to work. Check that your filters are correct, check that jest is updated. If you want to share your project I will be happy to find the time to try and help as well.

There are so many benefits of using a more moden target. From speed to size to syntax, the benefits are clear.

Couldn’t agree more with the modernization efforts. Too bad documentation is so scattered and the defaults that most tools use still rely on 14-year-old tech.

On subsequent runs, also including @swc/jest as a transform, it’s totally acceptable.

As always, thanks for your input. It’s good to understand your opinion on the matter as well.


1 Like

I experimented with swc a bit, and it seems to be a wonderful tool. My only “fear” is how fast tsc advances and whether or not swc can catch up. But I really want to move to swc instead of tsc during local development. Time is the only reason I haven’t tried it out yet :slight_smile: