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