Babylon.js: Get rid of *.module.d.ts and update docs

[deltakosh]

[zakhenry]

In this can you please also look into the regression with import behavior?

I use the spread pattern of import { Vector3, Scene } from 'babylonjs pattern extensively, and the latest update to split out modules has made the variables become untyped. For this reason I'm not willing to make the jump to alpha3.5 :(

It looks like using import * as BABYLON from 'babylonjs works fine with types, but this is a bit painful to add as prefixing all members with BABYLON. doesn't fit with our code style guidelines.

Additionally, the spread technique should be encouraged, as it allows for the framework to be safely fragmented into separate files allow for tools like webpack to do efficient tree shaking etc

[RaananW]

Hi @zakhenry ,

The spread operator should be working fine:

and

A few questions for me to be able to handle this:

• What package version are you using?
• TypeScript or JavaScript?

Regarding the difference between the spread import and namespace import - at the moment it won't make any difference when building your project. I agree that it is encouraged, but tree shaking won't work due to the way Babylon is currently built. When I get to the point that I have the time to fix the dependency tree, you will be able to benefit from it.

[zakhenry]

@RaananW hmm, I just downloaded VS Code to check and the types are working ok, so this may be isolated to a Webstorm issue. I'll investigate further.

I'm using

├── [email protected] 
└── [email protected] 

with typescript (in an angular cli application)

Yea I understand tree shaking won't do much at the moment but if I use the right syntax it might just work some day for free ;)

[RaananW]

@zakhenry , thanks for testing.

As I do want Webstorm users to benefit the new imports, it would be great if you can check what happened. Might be cached old declaration file? Or that Webstorm simply doesn't support export = BABYLON in a module declaration?

[zakhenry]

@RaananW no problem, I've narrowed it down to the change that wrapped export = BABYLON with the declare module. This fixes the issue for me:

// declare module 'babylonjs' {
    export = BABYLON;
// }

[RaananW]

That's interesting.

I will run a few tests on my side and see how we can make everything work correctly. We might get it to work with namespace exporting as well.

I would expect all tools to work the same, but it seems like being naive is not a very smart thing to be :wink:

[zakhenry]

Hah yea it is crazy considering Webstorm is using the TS language service, though perhaps not exclusively?

[RaananW]

May I ask for the TS version as well? I was just thinking about this - I am actually using webpack to compile, so it has nothing to do with the IDE

[zakhenry]

@RaananW yea I'm using [email protected] but I'm pretty sure that's not the reason as it compiles ok (angular cli also uses webpack under the hood). It must be related to how Webstorm links types. I might raise an issue on Webstorm if we can be sure it's the issue but in the meantime I think unwrapping the export results in correct behavior

[RaananW]

Nope, it doesn't. That's why I implemented this way. Removing the module declaration results in compilation errors due to the types not found in submodules. The submodules are using reference types (/// <reference types="babylonjs"/>) to assure they have the right references from babylon. It will work if you only use the core, but will break if you use any other module.

If it compiles, it is not a problem with typescript or the implementation. Seems like Webstorm doesn'T get along with export declaration in string-modules.

[zakhenry]

@RaananW ah. yes you are right, I just tried manually editing the module declarations, and while Webstorm was happy, the compiler failed with post-process and loaders.

[RaananW]

So it does seem to me like a webstorm issue. I wonder if other IDEs have the same problem

[zakhenry]

@RaananW yep, definitely a Webstorm issue, interestingly I've discovered it partially works - I can click through to the definition of methods, but not classes, or properties of child members.

If I uncheck use language service in Webstorm, it completely breaks, and errors are thrown throughout, so I suspect that Webstorm is running a hybrid of their own interpreter and the bundled language service.

I'll see if I can get a minimum reproduction without Babylon to show the Webstorm team

[zakhenry]

@RaananW ok issue raised against Webstorm: https://youtrack.jetbrains.com/issue/WEB-28946

[zakhenry]

@RaananW good news, turns out Webstorm has a fix in their latest EAP release

[RaananW]

Awesome! So I can close this :smile:

[zakhenry]

@RaananW uh yea, assuming this is why @deltakosh raised the issue in the first place? I kinda hijacked the issue sorry