They currently do not list their side effects so you need to create imports targetting modules and not the index files to benefit from tree shaking. we are currently hard working to list the side effects and enhance the discovery.
You either need to define earcut as a var in webpack or you can import earcut and pass it to the constructor of the PolygonMeshBuilder iin the 4th parameter. I ll add some part in the documentation for this today.
@sebavan thanks a lot, found it.
the problem is that Iâm using MeshBuilder.CreatePolygon which doesnât pass the earcut parameter to `PolygonMeshBuilder.
Iâll open an issue.
btw you have a typo in the docs âPlease not that you can not mix ES6 and our legacy packages.â
Deployed â@babylonjs/core@4.0.0-alpha.18â and â@babylonjs/gui@^4.0.0-alpha.18â to production env already. besides the issues I already opened everything works perfectly!
major improvement in loading times, thanks. (which was one of our challenges)
Iâve tested the new alpha in both angular and react, and all typings work out of the box, and the bundle size is way down, so awesome job with the modernization
I think we should just release as @latest for all @babylonjs/*
Otherwise people will get the old alpha.
then when we release 4.0.0 we can start tagging the new releases as @next since that seems to be what most frameworks do.
We could setup a CI to automatically do a @dev release also, that could mirror the master branch.
So:
@latest = latest semver release @next = 4.1.0-beta @dev = 4.1.0-dev.master-dc36dbc (where the last bit is the sha1 git hash)
That way we can always force install a specific version to test if a bug is present.
But also for some of us that are on the bleeding edge, can install the latest build.
Some might say that you should install the @dev builds directly from github, but since that doesnât contain our builds, thats a no go.
I recently helped angular @ngxs to do something like this using circle ci.
So if you need any help with setting up a CI server I could be of assistance.
We thought about @dev with @Deltakosh and we are afraid to bloat the versions as the number of push to master is pretty high. CI would not be an issue as we already have the gulp and npm publishing automated scripts.
About @latest, we are relying on @next, as we were using @preview on the babylonjs packages I wanted to stay consistent with those in versioning. That said would be easy to change as well. I even wonder if I could push both tags
@Deltakosh I let you weight in but all would be easy on our side (aside the double tag as I have no idea if it could work), I have no pref at all, the easier for the community the better