Firstly, I’d just like to say that babylonjs is a great project and it has saved me a lot of time and effort on my current game. Keep up the good work all!
I have been using the es6 version of babylonjs for a few months now. I use it for the tree-shaking and syntactic sugar advantages. My project is fully javascript (i.e. not typescript) so I can enjoy very fast iteration times simply refreshing my browser when coding against @babylonjs.
However, this was not straight forward to achieve.
Consider the following:
import { Vector3 } from “./@babylonjs/core/Maths/math.js”;
In a pure js project this will fail in all modern browsers because @babylonjs itself uses extensionless and unqualified paths when doing internal imports. For example in math.js we have:
import { ArrayTools } from “…/Misc/arrayTools”;
import { Scalar } from “./math.scalar”;
This syntax may eventually be supported by import maps and the like, but for now this does not work natively in any browser afaik.
So to achieve coding against @babylonjs in pure js I perform source transformation to rewrite all the illegal imports into legal ones using jscodeshift. This is an automated process and takes around 30s on my machine. Doing so I can then import any class from @babylonjs freely.
I would like to share a mwe of this setup for any users or contributors who may be interested in how it works.
Now onto my actual points for discussion:
Is a pure js es6 workflow something babylon maintainers are interested in providing? Or is typescript the expected workflow?
For including babylonjs in node can maintainers consider adding “type”: “module” to the @babylonjs/core package.json so node can use it as a es6 module?
I do not see any issue either with the second point.
The absolute best would be to leave it on the users to transpile if they need to to es5 but as we figured it was already painful for some users to consume es5 we did not move to pure es6 as adding Babel as well to their toolset was a bit more complex. I wonder how we could benefit from the best of both ?
Is it fair to say the current es6 distribution basically assumes the developer is using webpack during development?
In my case I am not using webpack, just pure js and refresh the browser to see changes. So I was wondering if there was any plans to support that sort of workflow at all with your es6 distributions?
One option is you run some sort of transformation of your es6 output to make it browser legal (in terms of es6 import syntax) like I am doing (not sure if babel is one way to do this? It is not what I used at least). This will still support developers who are using webpack and also those who wish to consume the library as pure js.
It assumes it would be used in a bundler so far. If not you could solve it at the web server level by redirecting the paths as we do during our local development.
It is currently a heated thread on the typescript repo to support it natively that we are actively following.
Hey I asked a similar question a while back. I ended up using es-dev-server, and I have no complaints - it’s exactly as you suggest: write normal JS and refresh when you make a change. Sometime this week I plan to make a topic to gather feedback on the web component I’m working on. ES6 modules are something I just finished documenting, and es-dev-server is in my npm dev tools.
“npm run dev” will run the special parts of the docs that require es-dev-server. It’s actually kind nice using the server since it does file watching and automatic reloading
Keep in mind, I haven’t shown this to ANYONE yet because I want to read things over a few more dozen times to make sure it all makes sense and works
Keep up the good work all!
and this is the exact issue we are following.