Can build v4.2, but not v5.0...why not?

Questions
1

When I follow the detailed setup instruction here (with this fix), I get a working scene. But when I specify 5.0.0-alpha.14 instead of ^4.2.0 in package.json, then npm i, and then rerun everything my terminal blows up with errors, things like below. Are there special config settings for v5.0.0, or any updated setup instructions?

**ERROR** in **./node_modules/@babylonjs/core/Debug/debugLayer.js** **2:0-38**
**Module** **not found** **:** **Error** **: Can't resolve '../Misc/tools' in '/Users/jon/Desktop/BJS ES6/node_modules/@babylonjs/core/Debug'**
**Did you mean 'tools.js'?**
**BREAKING CHANGE** **: The request '../Misc/tools'** **failed** **to resolve only because it was resolved as fully specified**
**(probably because the origin is a '*.mjs' file or a '*.js' file where the package.json contains '"type": "module"').**
**The extension in the request is mandatory for it to be fully specified.**
**Add the extension to the request.**
@ ./src/app.ts 3:0-43
2

I dont think v5 is availble on npm.

3

It is, and it installs no problem: babylonjs - npm
I just can’t get it to build even though the exact same setup builds as 4.2.

4

Feels like some form of a configuration key is a bit off (or doesn’t support something we are doing :-)). Any chance of sharing the project you are trying to build? We constantly learn from each and every project we examine.

5

Thanks for the response @RaananW . The project is just the setup step from the Build a Game tutorial in the docs, which works as v4.2 but not as v5.0. I’d love to understand what I’m not doing correctly. Here is a repo if that helps: GitHub - jonarnold/bjs-latest

Thanks in advance!

6

Hi,

This seems to be a compatibility issue with webpack. You will need to add the following rule to webpack’s configuration:

            {
                test: /\.m?js/,
                resolve: {
                    fullySpecified: false,
                },
            },

@PirateJC - can you check where it can be added in the docs?

1 Like
7

Yeah @RaananW that totally fixed it, thank you. (Oh how I wish I actually understood webpack…)

8

I don’t think the people developing webpack really know webpack :wink:

If you are interesting in understanding what the issue is - Module | webpack

It is a combination of webpack’s new default behavior and the way we are packing the framework

2 Likes
9

For anyone else encountering this with the relatively recently released react-scripts 5 (part of create react app - I don’t want to eject the webpack config) that includes webpack 5, I fixed this by patching the webpack default fullySpecified to false - patch-package - npm (I didn’t have success attempting to patch react-scripts, though I assume that can also be done)

Here is the patch webpack+5.70.0.patch

diff --git a/node_modules/webpack/lib/config/defaults.js b/node_modules/webpack/lib/config/defaults.js
index bfc8b29..716fc53 100644
--- a/node_modules/webpack/lib/config/defaults.js
+++ b/node_modules/webpack/lib/config/defaults.js
@@ -513,7 +513,7 @@ const applyModuleDefaults = (
 			resolve: {
 				byDependency: {
 					esm: {
-						fullySpecified: true
+						fullySpecified: false
 					}
 				}
 			}

Do note though that this was a pain to fix, I imagine encountering this problem could scare off newcomers to Babylon. Something is definitely going wrong here, so IMO this should be either fixed on the babylonjs side or bjs should push back on the webpack default (I don’t know enough about ES modules to say which is the more reasonable approach). cc @sebavan as I get the impression you’re heavily involved with the build system along with Raanan?

10

Cc @RaananW

11

We have resolved this issue for quite some time now, and 5.0.0-rc.13 doesn’t require fullySpecified anymore.
I just tested that on a side project to be sure - both false and without the definition. With failed, but because of a webpack related issue and not babylon itself.

What version of babylon are you using? Can you share the error you are seeing?

12

Yes, I have this issue with 5.0.0-rc.13. To clarify, the webpack default is true. I’m fixing it with the above patch that I apply to my local version of webpack that changes the webpack default to false.

Anybody using create-react-app’s inbuilt react-scripts package with 3,302,303 weekly downloads will have this issue, and can only solve it either via ejecting the webpack config (a massive pain in the butt, I don’t want to manage the webpack config myself, it’s why I’m using create-react-app) or by patching react-scripts/webpack, which is also a pain to do.

Imo, it’s also a bad user experience for anyone even without react-scripts to have to modify their webpack config to get it to compile with babylonjs

Given how the change is a one liner and there seems to have been relatively extensive discussion on webpack 5.0.0-beta.30 Module not found: Error: Can't resolve '../../core-js/object/define-property' · Issue #11467 · webpack/webpack · GitHub it seems unlikely it will be changed without significant pushback from major libraries

Related threads on the typescript repo: Provide a way to add the '.js' file extension to the end of module specifiers · Issue #16577 · microsoft/TypeScript · GitHub Provide a way to add the '.js' file extension to the end of module specifiers · Issue #16577 · microsoft/TypeScript · GitHub

It’s not clear to me what the solution would be for you to fix it on bjs side (can you put .js on your filenames as the typescript threads suggest?)

For reference the 223 errors I’m getting are like those mentioned in the OP

image
image3071Ă—536 51.7 KB

It does seem like you’re pretty committed to ES modules, but if I were you, I would abandon the disaster that they are. In the past I spent several hours trying to get Bjs in headless mode to run on my server in node (replicating animations etc is practically required for fully server authoritative games) and ended up giving up. I couldn’t use module: ESNext in my tsconfig as I would then have to be an es module myself (which I cannot do because ESM doesn’t support features I require), and I couldn’t use module: commonjs and then import a ESM library.

I think this thread sums up the problems with them pretty nicely: ES Modules are terrible, actually · GitHub

A big reason to use babylon.js over three.js is because its lack of breaking changes is supposed to save developer time. This is doing the complete opposite!

13

I would love to get why you’re saying this. Can you elaborate? My expectation is that users should not be concerned with our changes

14

Before I fully answer, could you share the project you are working on? Maybe a simple github reproduction so I can test that locally?

15

Ah, I do apologise - one of my dependencies had an earlier version of babylonjs, which was causing the issue. I think my judgement was clouded by my distaste of es modules :smiley:

Given this works @Deltakosh I can’t make such a strong argument, though I can still say I spent something like 10 hours trying to get babylon working on my server (with NullEngine) but never managed (because of es modules). Though running bjs in node is a completely separate issue to here.

I didn’t (and still don’t!) have a good understanding of the ts/js compilation ecosystem. I spent time messing about with my tsconfig and attempting to convert the bjs code from esm to commonjs with babel but didn’t have the understanding to get it working.

I actually figured out how to get it working today, but only as a result of googling “why are ES modules so bad” in my frustration, which took me to this article ES Modules are terrible, actually · GitHub which mentions this package the author made - fix-esm - npm

Is there another way of getting it running in node? Very possible I’m missing something obvious or this whole thing is the result of something I’m doing wrong

The overall impression I get of ES modules is they don’t play nicely with the overall node ecosystem and it feels like they try to force you to use them yourself - both which are parts of why I find them so frustrating

16

ES modules are great! If everything plays nicely with them. But once you have a version mismatch or a package that is not supported it’s going to be a lot of fun understanding the issue…

I’ll be happy to help with a node version if you have a project you can share. I’m pretty sure it’s just about solving a few kinks in the code.

1 Like
17

My experience has been that they don’t play nicely with everything else :wink:

But this I can do: GitHub - MCArth/bjs_esm_node_test

The steps I took were

npm init
npm i @babylonjs/core@^5.0.0-rc.13 ts-node

create file index.ts with only

import "@babylonjs/core"

create npm scripts start with command ts-node ./index.ts

npm start

observe it cannot work with either module commonjs or module esnext

(node 16.13.0)

18

If you look at the ts-node doc, you can notice that to enable support of esm you need ts-node - npm

  1. add this in your tsconfig:
"ts-node": {
    // Tell ts-node CLI to install the --loader automatically, explained below
    "esm": true
  }
  1. Add the following to your package.json:
  "type": "module"
  1. Change you module output to "module": "ESNext" in your tsconfig.
1 Like
19

See, and this is the path that babylonjs is leading poor stray developers down by becoming an es module :wink:

I understand I’d need to be an es module myself to use babylon in node (without resorting to hacky tooling). I was tricked into attempting to get my project working as an es module about a year ago, spent days trying to get everything working, and ended up abandoning the conversion along with the module that required it (and it genuinely does feel like tricked, given the amount of time I wasted on it)

Perhaps things have gotten better over the past year (I encountered a lot of things I needed that were a work in progress) , but from a brief google I can see that some issues are still unresolved such as Invalidate cache when using import · Issue #307 · nodejs/modules · GitHub

Given the lack of maturity of ESM I can’t justify using it in my current, relatively large (30k+ LOC) project

20

Doesn’t this only apply to people you want to contribute to BJS?

Maybe not. I think I see your point. If BJS doesn’t play nice with your library/framework of choice, then you need to take some extra steps which aren’t convenient. I wonder how often this happens.