Use Rollup to bundle Babylon. but

[TomBerend]

Here’s a repo that uses Rollup to bundle BJS. Fast, lightweight, and fun. But keep reading…

tom-berend/asteroids

I’m a newcomer to this community. And just I’m learning TypeScript ( so double Newbie!). I thought writing games would be a fun way to learn. But almost immediately I found a bug in BJS https://playground.babylonjs.com/#6QF3KP#3 - watch the middle pins.

I figured out the problem and solution from the Bullet/Ammo site. And thought, well, if it must be fixed, then I probably should fix it. More fun things to learn. So I forked BJS and downloaded it.

Two problems. The BJS build system is, well, impressive. I’m using a laptop, and it has never worked so hard for so long. It was smoking. The builder carries the legacy of every step of Babylon’s development. @trevordev shared this with me… Our Journey into the Module World. – Babylon.js – Medium Makes me feel better about the two days in hell I spent getting Rollup to work.

And BJS isn’t really written in TypeScript, there are all sorts of leftover JS chunks. TypeScript and VSCode have amazing tools available to refactor and improve big projects, but they need a cleaner codebase to start.

My guess is that very few of us are willing to touch the BJS codebase because of these two problems.

==================

OK, grab my repo (never mind the silly name, I was fiddling a game involving asteroids). Save it as a peer to the Babylon.js repo (I have them both in my /htdocs directory). run ‘npm install’ and then run ‘npm dev run’. Don’t laugh at my code, this is barely more than my ‘Hello World’.

It will fail. There are some circular references in Babylon that need to be fixed first. But you can get basic Babylon running with this ugly patch: Open 'Babyon.js/src/engines/engine.ts and

1. comment out the "import { Materials } … " statement on line 16.
2. neuter the _drawMode() function starting on line 3098.

==================

Now I need to fix the circular references before I can fix the Ammo problem. And that’s definitely not Newbie territory. There’s a bunch of draw___() functions in engine.ts that need to be moved out (probably to the render directory), and then the call to _drawMode() eliminated (it isn’t necessary when instantiating the engine). I’m happy to give it a try, but I need a mentor.

Using Rollup as a builder, with the speed and modern tooling that it provides, might be a wonderful platform to clean up the codebase. So I’m sharing what I have, and asking for feedback from the community.

[Deltakosh]

@TomBerend

And BJS isn’t really written in TypeScript

This is not true Babylon.js is entirely written with TypeScript. I don’t know what was leading you to this but babylon.js is compiled with TS. Entirely.

To build babylonjs, maybe this doc will help: https://doc.babylonjs.com/how_to/how_to_start

[TomBerend]

By “not TypeScript”, I wasn’t trying to troll. All valid JS is also valid TS. And I’m still working my way through Basarat, so I’m not the guru on anything.

I meant that there was JS-style code that Typescript couldn’t validate, and VSCode couldn’t navigate. For example, the function below stuffs a method into prototype, which confounds TSLint and prevents VSCode from finding definitions and references. Since it might return null, TS can’t validate code that uses it. You must disable TSLint inside VSCode because the number of warnings are overwhelming.
This neuters the wonderful gifts that TS brings.

And yes, I had no trouble building Babylon by following those excellent instructions. But touching the code without better tooling is above my pay grade.

a

[sebavan]

I can not understand why you have those issues with ts. We actually rely on tslint locally during the build and we also have checks for circular dependencies. Actually our modern build (ES6 target) only relies on tsc to emit the full code. What version of TS are you using ?

[TomBerend]

I’m using TS 3.4.5 and Babel7. I turned on TSLint again, and the flood of errors was gone, it may have had something to do with my attempts to configure TS for Rollup. I may have turned off strict checks somewhere.

One of my issues is that I try to use basic types like Vector3, but Babylon uses Nullable, possibly for legacy reasons. TS complains when I try to assign one into the other.

Here are other circulars and missing exports reported by rollup (excluding the one I disabled in engine.ts):

Rollup took about 40 seconds to do this on my laptop, but of course the cache was in place.

[sebavan]

Actually there is at least for the first one no real circular dependency

Mesh indeed needs material as it uses static constants from it (this should be used through the constants file in engine) but Material imports mesh only for its type. Typescript is normally clever enough to detect it.

The generated code from ts does not have import mesh in material but only:

import { serialize, SerializationHelper } from “…/Misc/decorators”;
import { Tools } from “…/Misc/tools”;
import { Observable } from “…/Misc/observable”;
import { Plane } from “…/Maths/math”;
import { EngineStore } from “…/Engines/engineStore”;
import { BaseSubMesh } from “…/Meshes/subMesh”;
import { UniformBuffer } from “./uniformBuffer”;
import { Constants } from “…/Engines/constants”;
import { Logger } from “…/Misc/logger”;

The bundle we create from Webpack would not work if that was actually the case.

It looks like an issue in some of the rollup/babel toolset not being able to detect Typescript import used for typings only but not emitting JS imports.

As a workaround you can replace the import mesh in material by
declare type Mesh = import("…/Meshes/mesh").Mesh; which is the explicit way to let the toolset know that there is no real imports but only typings.

Also your issue with Vector and Nullable is pretty strange. I can not figure what would cause that.

[TomBerend]

I’m pretty sure it is not the CODE that is wrong, because Babylon runs fine.

I keep running into ‘red marks’ like this - to the point where I couldn’t use F8 lint because it examined each one again and again. I think the physics engine interface needs a bit of love, and I’d like to try it. But the Gulp process is overwhelming.

[Deltakosh]

The gulp process is quite complicated but this is because we check a lot of things. If you follow the doc I linked you (and you make sure to have node 8 or 10 + gulp 4 already installed) it should work flawlessly

[sebavan]

Ohhhhh wait are you placing your own code in the repo ?

This might break everything indeed you need to consume it through npm then it would be piece of cake to use rollup against it.

And if you use the es6 version you can run gulp npmPackages-es6 which is way shorter than the full build to generate some local version of the lib you can npm link against to test locally.

Else the localDev folder would be the easiest.

[TomBerend]

@sebavan thank you for the import typings, I will try that, and add some of the missing properties to Mesh.

yes of course npm. but I wanted to fix a bug in the Ammo interface.

I started by putting my build environment in ‘localDev’, but must change .gitignore and remember not to commit it. it is more natural to have a Babylon.js directory in my project. but rather than explain, I set them both as peers in my example repo.

Thanks again.