Recast plugin problem with ES6 Babylon build

Hi everyone and sorry for directly pinging you @Cedric , I know you are the master of navigation :wink:

Updated my project into Babylon 5.0 alpha version 44 from version 22. Now I am facing an issue with the navigation RecastJSPlugin initialization. What I’m trying to do is feed the actual Recast instance to the plugin, like so:

import { Recast } from './recast/index'
navigation = new RecastJSPlugin(Recast)

The recast/index file basically holds the Recast library and I can import it from there. The reason I am doing this is the fact that I use the same import on the frontend (browser) and on the server (null engine). This used to work fine before, but now it gives the following warning:

RecastJS is not ready. Please make sure you await Recast() before using the plugin.

And if I try to await Recast() before the plugin initialization, everything freezes… Any idea how to fix this? It used to work perfectly :frowning:

Did you update the Recast-detour package to version 1.4?

1 Like

I tried it now yeah but there are some problems. The recast library is not fully ecmascript module compatible since there is no "type": "module" set in the package.json… So the build systems have problems importing it I think.

I think I managed to get this working, again by doing some hack and slash to the Recast.js itself. This is not ideal at all as I have to keep a manual version of the file :smiley:

After this I have a index.ts file where I import & export the hacked Recast.js

// @ts-ignore
export { Recast } from './recast'

And after this, I can import Recast to my project with:

import { Recast } from './recast/index'

const r = await Recast()
navigation = new RecastJSPlugin(r)

It now doesn’t give any errors but I have problems with running NullEngine so I can’t be 100% sure if it does actually work… Creating a multiplayer game with pathfinding running on the server :slight_smile:

I still hope there would be a better way to import this into a project than this, not sure what I do wrong.

The null engine part should be good soon. regarding imports maybe @RaananW could help you @Cedric ?

1 Like

Esm nonsense and webpack in general make me rage so hard. How do they not realize that esm dictates an immutable namespace imported from proper uri identifiers, including file ext. Conceptually, bundling and esm are diametrically opposed. I deleted all the badwords good job me. :person_in_lotus_position:

I can totally relate to that :slight_smile:

I noticed you have changed the esm to a UMD in order for it to work. I wonder - would adding module to package.json work here?

I have quite a few things on my plate right now, but i’ll try finding time to see how we can improve that. it feels like we should be able to pass the import/promise to babylon in order to construct the plugin correctly. And we should support both UMD and esm.


Thanks for looking into this!

Totally agreeing as well :sweat_smile: I hate how fragmented the JS ecosystem is now… ES modules is the way of the future for many reasons, but we are still not there… Too many UMD/Commonjs libraries still available.

I try to use the “best new/hipster stuff” but in JS world it usually means extra work. Have had problems with Vite (esm bundler) in the client/frontend and with Node.js (support is a really new thing…).