Babylon.js: npm repo: included extensions do not work when BABYLON is imported

The npm repo for babylonjs includes all the extensions from babylonjs/dist however, none of these work out of the box.

recreate

npm install --save babylonjs

in the file where the babylonjs scene will be created in:

import * as BABYLON from 'babylonjs

Now all of core BABYLON is available.

The folder structure of babylonjs after npm installing file-structure

Problem

Attempting to use an extesnion such as GUI or the textures the typings file throws a Property 'GUI' does not exist on typeof BABYLON because these types are not defined in the babylon.module.d.ts file. This type error is fatal and causes the node app to crash.

solution: add all these default extensions to the type definitions file, since they are included by default in the npm repo.

Problem 2

The type definition file babylon.gui.d.ts for the GUI extension seems incorrect to me. it declares the top level module as so declare module BABYLON.GUI {} which is the same as nesting modules declare module BABYLON { module GUI {} }, it does not seem to inherit anything from the main BABYLON module. The image below is taken from the typescript docs and states that modules aren’t merge-able which supports this thought. image

This leads to some issues because every property reference to the BABYLON module inside babylon.gui.d.ts is undefined since there is no inheritance. I believe consolidating the two type definition files would fix this.

The workaround I’m using now involves disabling types for babylon, and editing the source code which will get overwritten after every npm install. This is far from ideal.

If this is a valid bug/feature I will be happy to make a pull request and help implement it, if it is an oversight on my part I would love some guidance on how to properly incorporate these extensions.

I posted a question on Stackoverflow, however, after research I believe this is more of a bug or feature request.

I also posted on html5gamedevs and spoke with Deltakosh who seemed happy to help as well.

About this issue

  • Original URL
  • State: closed
  • Created 7 years ago
  • Reactions: 1
  • Comments: 38 (33 by maintainers)

Most upvoted comments

So, good people, it is time for a (very happy) update.

Starting with babylonjs 3.1.0-alpha3.4 (and all of its modules) you can do the following:

import * as BABYLON from "babylonjs";
import * as GUI from "babylonjs-gui";
import "babylonjs-materials";

console.log(BABYLON, GUI, BABYLON.SkyMaterial);

Don’t forget to add babylonjs (and the modules you are loading) to the types part of tsconfig.json:

"types": [
            "babylonjs",
            "babylonjs-gui",
            "babylonjs-materials"
        ]

submodules available are listed here: https://www.npmjs.com/~babylonjs

Issue tested and closed. 🎆

I came to the same conclusion. @raananw will work on this restructuring

Ehh same thing happens, I understand the issue now.

Usually with npm modules you will define the entry point of the module in package.json with the main field.

The main babylon library works because the package.json in the root defines babylon.max.js as the main file. As shown below, and babylon.max.js properly exports BABYLON

image

Solutions

  1. The only way to define babylon.gui.js is to reference it in babylon.max.js, since you can only have one entry point in the package.json

This can be achieved creating a module for babylon.gui.js (preferably a module that doesn’t include the name BABYLON so it doesn’t make double declaration errors) and then importing this into babylon.max.js at the bottom to append it.

  1. An even better solution in my opinion, and one that can be easily used for every other extension as well is to create an npm scope and house all the extensions in their own npm repo inside this scope.

The scope would be like so:

for the main library either @babylon/babylon or @babylon/core

@babylon/extension_name for all the extensions.

DefinitelyTyped uses this structure with great success, and users are able to effortlessly extend the repo with their own type definition files.

Angular does this as well to make their framework extremely modular, and easily extendable.

If we do this for BABYLON and create a standard for it, I believe the added structure would increase the overall quality, maintainability, and predictability of extensions.

This is kind of a completely different feature request than what was originally proposed, though it will fix everything, making all extensions easily accessible with a very clearly defined structure.

I’d love your opinion on the matter, and if it’s good I’ll create another feature request to outline it.

@RaananW is working on it and we expect a fix by end of week 😃

The type definition is a module.

However, the actual js file which babylon.gui.d.ts defines is not a module, though. So I don’t believe any of the javascript is being included with the import statement.

All of the extensions’ js files should be turned into modules, otherwise I think it’ll be impossible to use them through node and npm.

I took a look at the babylon.max.js and babylon.js files and they declared themselves as modules as pictured below at the very bottom of the file.

screenshot from 2017-07-22 22-48-31