Types broken in Webstorm IDE for Bab 5.0.0 beta

Questions
1

Typings work fine if I regress to 4.2.x, but upgrade to 5.x and they break every time.
Only upgraded to 5.x because doc.babylonjs.com is already giving 5.x answers.
Using typescript 4.5.2

tsconfig.json

{ compilerOptions: { 
    ...
    "types": [
      "node",
      "webpack-env",
      "jest",
      "@babylonjs"
    ],
},
  "include": [
    "src",
    "node_modules/@types/jest/index.d.ts",
    "node_modules/@babylonjs/core/types.d.ts",
    "node_modules/@babylonjs/loaders/types.d.ts"
...
2

if you consume babylon using imports, there is no need to define the “types” in your tsconfig. the types will be loaded automatically for you. You also don’t need to include them in the “include”. Just make sure you import the right classes in your ts code and you are good to go.

3

I do consume it as an NPM, yes:

package.json

  "dependencies": {
    "@babylonjs/core": "^5.0.0-beta.4",
    "@babylonjs/loaders": "^5.0.0-beta.4",

Thanks for the advice. I’ve removed those tsconfig lines in previous attempts, but still the same problem persists. Removing again:

tsconfig.json

    "types": [
      "node",
      "webpack-env",
      "jest",
    ],
    "outDir": "appOutDir"
  },
  "include": [
    "src",
    "node_modules/@types/jest/index.d.ts"
  ],

Still no joy with Bab 5 typings. Yes I even restarted the IDE.

Testing reversion to Bab 4 again:
$ npm i --save @babylonjs/core@4 @babylonjs/loaders@4

… Bab typings restored, complete with a correct error message about BoundingInfo::encapsulateBoundingInfo() not existing (a 5.x feature). All good with 4.x still.

Re-installing Bab 5:
$ npm i --save @babylonjs/core@preview @babylonjs/loaders@preview

package.json reflects:

    "@babylonjs/core": "^5.0.0-beta.4",
    "@babylonjs/loaders": "^5.0.0-beta.4",

tsconfig.json still as you recommend, no Bab references in “types” nor “include”:

    "types": [
      "node",
      "webpack-env",
      "jest"
    ],
    "outDir": "appOutDir"
  },
  "include": [
    "src",
    "node_modules/@types/jest/index.d.ts"
  ],

Typings in Webstorm… busted again, no joy with 5.x What’s different about 5.x that breaks Webstorm’s Intellisense functionality (autocomplete, etc) ? Im at a loss.

4

How about this kind of setup:

Does this fail on typings as well?

The only thing we changed is moved the package to be defined as a module, which it should be.

5

Tested and yes it does seem to fail the same way for me.

I noticed you’re using 5.0.0-alpha.61 there, tried that in mine, no change.

Fell back to 4.2.1 and Webstorm’s types awareness comes right back online - dont even have to restart the IDE, the change is auto-detected.

Maybe there’s an important diff in your tsconfig, I’ll dig for that today. Hard to learn Babylon without TS support in the IDE, although it’s also difficult (though less so) learning 4.x when the online docs are giving 5.x answers.

I dont suppose the 4.x API reference is preserved? I could remain on 4.x for a while longer then.

6

This project fails as well? The same way?

Then Webstorm doesn’t read typings correctly. Or the packages. I havne’t used any intelliJ products for quite some time, but, of course, we want to support all IDEs available.

Can you try 2 things (independently)

  1. Go to node_modules/@babylonjs/loaders/package.json , and try to remove this line:
    "type": "module"
  2. Try using babylonjs and “babylonjs-loaders” instead of the es versions. they should have the same typings and apart from packing, there shouldn’t be a different during development
7

No, sorry! Your project appears to be fine.

8

Try to copy the setup to your project, make sure everything is set up correctly. I hope it can provide guidance!

9

Weirdness afoot. I started copying and testing your tsconfig lines, and the problem immediately vanished.

Tried reverting that change to confirm I’d found something - nope, the problem remained gone.

Something spooky going on between tsc and Webstorm I guess, maybe something cached somewhere, but Ive got Bab 5 with types now so Im inclined to just leave it alone and resume working. B-)

If the problem comes back, I’ll resume the investigation. If anyone else has this problem - try changing your tsconfig “module”, then change it back. I went commonjs->esNext->commonjs and my problem disappeared (for now!)

2 Likes