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?
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?
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.
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 so we are on the right track.
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?
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.
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