Repro: Babylon.js Playground
We’re in the process of converting a project from Webpack to Vite, and one blocker is with our use of NullEngine in Web Workers to load compressed GLBs and generate navmeshes.
With Vite, workers are created as es modules, and module-type workers do not have access to importScripts. If you try to use SceneLoader to import a meshopt-compressed GLTF, it will trigger a call to importScripts in _LoadScriptWeb from core/src/Misc/tools.ts and error.
I’ll be sending a PR
3 Likes
Thanks a lot for the contrib !!! 
@sebavan I have to use the async import(), but _LoadScriptWeb is not currently async and I see this lint rule forbidding .then(). Would you prefer I change _LoadScriptWeb to be async (it has no return value, so should be safe) or use an async iife here?
I think in this particular case we should use the .then and .catch as it matches with some Babylon Native API with a linter disable bypass and a comment
@sebavan thanks for the help - one more question:
When testing backwards compatibility, I see the proposed new code causes this warning to be printed in webpack builds:
WARNING in ../node_modules/@babylonjs/core/Misc/tools.js 450:20-37
Critical dependency: the request of a dependency is an expression
@ ./mainline/babylon.ts 68:0-51 70:0-19 71:0-18
@ ./mainline/index.js 10:0-42 45:26-43
It is webpack reporting that the new import() can’t be statically analyzed for dependencies. This is fine, of cource, because the load script utils are only ever used to import external sources. I can add a /* webpackIgnore: true */ comment here to explicitly mark it as an external dependency and squash the warning, but I’m not sure if you want bundler-specific directives in the source
Looks like a @ryantrem question
A few thoughts:
- I think fully using async/await would be best, but to reduce risk close to the 9.0 release, I think keeping .then/.catch with eslint suppressions is fine.
- I think falling back to
import in the catch also seems fine to deal with module workers.
- My preference would be to avoid bundler specific directives, and I think it can be done with something like:
const dynamicImport = new Function("url", "return import(url)");
dynamicImport(scriptUrl).then(...).catch(...);
That said, I see we recently used import with a webpack directive just like this in another place. @RaananW do you have an opinion?
1 Like
Good question
We have /* webpackIgnore */ only in tools (i.e. - playground and the experimental snippet loader), mostly becasue we are the ones packing them. The framework itself should not have any bundler-specific code IMO.
1 Like
Thanks everyone. I’ll send it up with the Function constructor workaround and the eslint disable comment
