Critical dependency: the request of a dependency is an expression - /webgpu/webgpu-graphics-device.js

[AlbertoMalavasi]

Title: Critical dependency error in playcanvas module with webpack

Issue description

When building my project, webpack throws a critical dependency warning associated with the playcanvas module.

The warning states

WARNING in ./node_modules/playcanvas/build/playcanvas.mjs/platform/graphics/webgpu/webgpu-graphics-device.js
Critical dependency: the request of a dependency is an expression

Steps to Reproduce

import * as pc from 'playcanvas';

export default class ViewerManager {

    constructor() {
        console.log(pc)
    }
}

Environment

Node: ^16.0.0 || ^18.0.0
npm: ^7.0.0 || ^8.0.0 || ^9.0.0
playcanvas version: 1.66.0
webpack version: ^5.76.3

Expected behavior

The project should build without any critical dependency warnings.

Actual behavior

Webpack throws a warning regarding a critical dependency issue in the playcanvas module.

[kungfooman]

Thank you for pointing it out!

Happens since #5711

We should stick to document.createElement('script') in src/platform/graphics/webgpu/webgpu-graphics-device.js

In addition to this webpack issue, we can also no longer use relative paths because of import.

[LeXXik]

I believe it is due to those 2 lines:

engine/src/platform/graphics/webgpu/webgpu-graphics-device.js

Lines 169 to 172 in 3fc8bf0

	const results = await Promise.all([
	import(twgslUrl).then(module => twgsl(twgslUrl.replace('.js', '.wasm'))),
	import(glslangUrl).then(module => module.default())
	]);

Here the guys suggest to explicitly convert to string:
https://stackoverflow.com/questions/42908116/webpack-critical-dependency-the-request-of-a-dependency-is-an-expression

However, it sounds like a webpack issue? Not sure the engine should support it, as it has chosen rollup.

[kungfooman]

However, it sounds like a webpack issue? Not sure the engine should support it, as it has chosen rollup.

We have to be agnostic about that, the engine (ESM files in npm package) are consumed by third-party bundlers to create a user bundle

[mvaligursky]

Any thoughts on this @slimbuck ?

[mvaligursky]

We have a mentioned of it here: https://forum.playcanvas.com/t/engine-release-v1-66-0/33297/3

[slimbuck]

The previous method of loading glslang with a script tag was actually loading a 'loader script' which performed the dynamic import (see here).

The loader script was downloading the actual wasm glue script via CDN (unacceptable) and using a dynamic import statement anyway (though it included the webpackIgnore comment and so worked with webpack).

So it seems we have two options to address this issue:

• add /* webpackIgnore: true */ to the import statement and update tooling to keep the comment (by default comments are stripped)
• use the string approach found by @LeXXik above

The second option is the simplest and least invasive.

Can anyone test that the following works correctly with webpack?:

        const results = await Promise.all([
            import(`${twgslUrl}`).then(module => twgsl(twgslUrl.replace('.js', '.wasm'))),
            import(`${glslangUrl}`).then(module => module.default())
        ]);

[kungfooman]

Can anyone test that the following works correctly with webpack?:

Just tested and it definitely works (red: as it is currently, green: with your fix):

[slimbuck]

Lovely - thank you so much! I'll merge the fix then.

[pavle-goloskokovic]

The issue still happens if webpack tries to use prebuilt es5 playcanvas engine (node_modules/playcanvas/build/playcanvas.js) instead the default mjs.

One possible solution is to add noParse option to the module section of your webpack config:

...
module: {
        ...
        noParse: [
            // ignore imports and requires in playcanvas build
            /playcanvas\./
        ],
        ...
}
...

[kungfooman]

Wow, what a chain of issues rewriting that dynamically added <script> to import, thank you for reporting - it makes sense, since template strings are transpiled.

Can't you use ESM version aswell if you put {type: "module"} in your package.json? Transpiling down to ESM should be easy, while you can't "up-transpile" the ES5/UMD version to ESM.

[marklundin]

It's likely this script import will be cause this issue as well.

[pavle-goloskokovic]

Can't you use ESM version aswell if you put {type: "module"} in your package.json? Transpiling down to ESM should be easy, while you can't "up-transpile" the ES5/UMD version to ESM.

@kungfooman I use Typescript so using default ESM import works, but my output target is ES5 and I import prebuilt ES5 version of the playcanvas engine to avoid needing to recompile entire playcanvas source code on each update during development and when creating production builds.

[Mistale]

We're in the same boat as @pavle-goloskokovic . While we can use ESM in our projects, it would require us to turn on transpilation of dependencies in node_modules to ensure that we can still support ES5.

In our case, webpack tries to resolve the dynamic imports at build time and spits out hundreds of errors stemming from files within the ESM-module folder of the playcanvas package. The noParse trick works well, but we would prefer if the issue could be solved on the playcanvas side rather than requiring downstream projects to use special webpack configurations in order to get the commonjs version to work with webpack.

[mvaligursky]

@marklundin is just cooking this one, any feedback?
#6090