Can't import the named export 'FilesetResolver' from non EcmaScript module (only default export is available)

[Mihai-github]

Hey, I'm trying to do some testing with the latest version of Livekit Client, 1.15.4, coming from version 1.10.0, and by upgrading the version I'm currently running of @livekit/track-processors, ^0.1.4, it stopped working throwing this error:

Argument of type 'ProcessorPipeline' is not assignable to parameter of type 'TrackProcessor<Kind, ProcessorOptions<Kind>>'

when doing:

await camTrack.setProcessor(VirtualBackground(url));

or

camTrack.setProcessor(BackgroundBlur(10))

So I've also updated to the latest version of the @livekit/track-processors package and now I'm having this issue:
./node_modules/@livekit/track-processors/dist/index.mjs
Can't import the named export 'FilesetResolver' from non EcmaScript module (only default export is available)

Does anyone know what's the issue, it's maybe I assume because I'm running an older version of react and react-scripts or I have to do some webpack configuration for .mjs files?

[lukasIO]

Are you using nextJS? If so, which version?

[antonyjaved]

I have the same problem

./node_modules/@livekit/track-processors/dist/index.mjs
Can't import the named export 'FilesetResolver' from non EcmaScript module (only default export is available).

Apparently, instead of index.js, the webpack goes to index.mjs.

Perhaps the pact was assembled incorrectly

[lukasIO]

• Are you using nextJS? If so, which version?
• Does it work with the default import of import processors from '@livekit/track-processors'; const VirtualBackground = processors.VirtualBackground?

[antonyjaved]

No, I'm using React without NextJs.
"webpack": "^4.29.6",
node: v16.20.0
I've tried use
import processors from '@livekit/track-processors';
But there are the same error

[lukasIO]

thanks for checking.
We define the two entrypoints like so:
https://github.com/livekit/track-processors-js/blob/main/package.json#L5C2-L6C30

So it sounds to me like your webpack version is picking up the wrong one?

[antonyjaved]

I think so too, but I still can’t understand why the wrong file path is selected.
I didn't set "type": "module" in the package.json, so the index.js path (not index.mjs) should be selected by default, but it doesn't.

And as as far as I understand, this problem exists not only for me.

[lukasIO]

We haven't had any other reports about this (apart from @Mihai-github, who seems to have fixed his issue)

Are you able to update webpack to see if the issue resolves then?

[sgrund14]

@lukasIO i'm having the same problem as well actually, in a create-react-app (react-scripts: 4.0.3)

initially, I got the same message:

./node_modules/@livekit/track-processors/dist/index.mjs
Can't import the named export 'FilesetResolver' from non EcmaScript module (only default export is available)

then tried to use CRACO to override webpack per this comment

// craco.config.js
module.exports = {
  webpack: {
    configure: (webpackConfig, { env, paths }) => {
      // Add a rule to handle .cjs and .mjs files
      webpackConfig.module.rules.push({
        test: /\.(cjs|mjs)$/,
        include: /node_modules/,
        type: "javascript/auto"
      });

      console.log(webpackConfig);

      return webpackConfig;
    },
  },
};

which fixes the FileSet resolver error message as seen above

But it creates this new issue in the subdependency of @mediapipe/tasks-vision:

./node_modules/@livekit/track-processors/node_modules/@mediapipe/tasks-vision/vision_bundle.mjs 23:18
Module parse failed: Unexpected token (23:18)
File was processed with these loaders:
 * ./node_modules/babel-loader/lib/index.js
You may need an additional loader to handle the result of these loaders.
| const c = "undefined" != typeof TextEncoder;
| function h(t) {
>   if (c) t = (a ||= new TextEncoder()).encode(t);else {
|     let n = 0;
|     const r = new Uint8Array(3 * t.length);

found a similar issue with @mediapipe and commented here, but wanted to see if you might have any insight as well

thanks!

[lukasIO]

looks like the issue for you might be the ||= operator used within mediapipe.
maybe preprocessing it with babel could help, but the mediapipe repo is probably the better place to fix this.

[sgrund14]

hmm, yea, tried adding that to the craco setup but to no avail. I'm wondering if you have to do something different to target subdependencies of your node_modules with babel, and if the mediapipe package is getting skipped in transpilation