next.js: `next dev` fails with webpack error when importing functions inside web worker

OMG, unbelieve that I was able to reproduce this. It happens when there are 2 different webworker sharing same dependencies.

https://github.com/Lagz0ne/web-worker-build-error

Those backgrounds are sharing those imports and those imports exceed a certain size threshold (the data file is pretty big). Only then the yarn build yells

webpack/runtime/compat
The "path" argument must be of type string. Received undefined

It won’t happen if we remove that data from the background bundle.

And, yarn dev works. yarn build yells that error

Next version is 11.0.1

@balazsorban44 You’ve got to be kidding, we’ve got several reproductions and this is impacting lots of people in production. I’ve brought this up with our company’s account rep repeatedly and been ignored, and here it also seems to be something the team would rather ignore than seriously look at our reproductions and solve.

Hey folks. We are definitely paying attention here and we will take action if we closed by mistake. Thanks for all the feedback and effort into giving us further reproductions 🙏

is this issue being addressed? it’s still a problem in Next 12 and the above workaround does solve it, however it adds 200K to our total gzipped bundle size

edit: it turns out this was only an issue for us on the server, so we were able to flag the workaround conf against isServer and keep our client bundle using the default Next conf. hope this helps anyone running into this

@Qeldrona thanks. I can confirm it works using your patch

others can find the reference here https://github.com/lagz0ne/web-worker-build-error/tree/bump-nextjs-version

Cheers

After spending some more time on this, I noticed that on the webpack documentation there is a property on commons for chunks: “initial” which is missing from next by default as far as I can tell and after adding that to my configuration I was able to add commons back into our config without the error. Curious if this works for others as well (note that minChunks number should be balanced based on your project size to get the initial bundle sizes that work for you)

cacheGroups: {
   defaultVendors: false,
   default: false,
   framework: {
     chunks: "all",
     name: "framework",
     test: /(?<!node_modules.*)[\\/]node_modules[\\/](react|react-dom|scheduler|prop-types|use-subscription)[\\/]/,
     priority: 40,
     enforce: true,
   },
   commons: {
     name: "commons",
     chunks: "initial",
     minChunks: 20,
     priority: 20
   },
 }, 

Thanks for the reminders everyone, and thank you @rauchg for stepping in!

I would like to apologize if someone felt ignored. I did - to the best of my abilities - try to reproduce the issue based on what the OP suggested (using with-web-worker), but I could not.

I also tried @lagz0ne’s repro https://github.com/vercel/next.js/issues/25484#issuecomment-867438124, and could not reproduce the problem with next dev, which is what this issue was about, according to my understanding. I should have been more clear in my closing comment though because I did see the issue while running yarn build, maybe I could have created the new issue myself and referred to that specific comment.

Once again, I do apologize, and I would like to assure everyone that I look at all comments in this repository, even on closed issues, and I would have eventually circled back on this if there were new comments/concerns.

That said, we took this issue up immediately with the rest of the team once I got available, and @sokra has already opened a PR at #34087 that should fix this issue.

Confirming same error also on next@11.1 after adding a second worker (works on dev, fails on build). Using the patch/config from @Qeldrona and @lagz0ne for now

I’m also running into this error on 10.2.3 and 11. This error is definitely related to the only web worker in our project (follows the with-web-worker example), commenting it out allows the build to run successfully.

Hi guys, thanks @rauchg for stepping in. I do apologize for all of my harsh words, just a matter of fact, words mean everything, we all definitely do better with our wordings. I guess the takeaway here at the end of the day is all about empathy.

I would make my statement less aggressive if I stand from the point of view of @balazsorban44, try to understand a little better about the rationale he takes.

Also, from @balazsorban44, the outcome will be quite different if he spent time to stand from our point of view, as end-users to decide what action to take. The opaque message comes with rushy action to close the issue didn’t do good there.

All in all, I do appreciate prompt actions, responses from Vercel, and eager to look for the fix, can’t wait to remove the ugly hack in the config file.

Cheers

thanks, @ColmanHumphrey, I think that makes sense, hot heated got me. I updated the repo with the upgrade https://github.com/Lagz0ne/web-worker-build-error to the latest nextjs, somehow the error displayed twice now

Hey @lagz0ne this bug frustrates me too, been waiting on a fix for a while, and it does seem like a somewhat inconsiderate oversight from @balazsorban44. So I totally understand where you’re coming from. But I think it’s worth expressing our frustrations as Nextjs users without getting too personal.

@balazsorban44 I don’t think this is how you are representing Vercel, if you follow the content of the issue before even too eager to just close issues, you should figure out that there’s a BIG ASS REPRODUCIBLE repo using create-next-app right here https://github.com/vercel/next.js/issues/25484#issuecomment-867438124. The repo is using nextjs: latest and IT IS STILL ERROR when you do yarn build.

To be very honest with Vercel, this bug fucks us quite a bit for a while and now a random guy just steps in and closes this as unreproducible. Are you freaking serious, @timneutkens

Confirmed @Qeldrona 's fix works for us.

Basically just added this to next.config.js

const _ = require('lodash');

const nextConfig = {
  webpack: (config) => {
    _.set(
      config,
      'optimization.splitChunks.cacheGroups.commons.chunks',
      'initial'
    );

    return config;
  },
};

module.exports = nextConfig;

For what it’s worth, we only had the one webworker in the app. Good thing you managed to reproduce it though!

Comparing against the splitChunks config for prodGranular in the current version of Next vs 10.0.0 (last good version we were on), I was able to pull these settings into mine and still compile successfully:

    config.optimization.splitChunks = {
      chunks: (chunk) => !/^(polyfills|main|pages\/_app)$/.test(chunk.name),
      minSize: 20000,
      minRemainingSize: 0,
      minChunks: 1,
      maxAsyncRequests: 30,
      maxInitialRequests: 25,
      enforceSizeThreshold: 50000,
      cacheGroups: {
        defaultVendors: false,
        default: false,
        framework: {
          chunks: 'all',
          name: 'framework',
          test: /(?<!node_modules.*)[\\/]node_modules[\\/](react|react-dom|scheduler|prop-types|use-subscription)[\\/]/,
          priority: 40,
          enforce: true,
        },
      },
    },

Unfortunately the rest are in TypeScript and there is little I can do on those ones. I tried pulling “commons” over and just setting minChunks: 1 and that threw the same error: The “path” argument must be of type string. Received undefined

webpack: (config, options) => {
    config.optimization.splitChunks = {
      chunks: (chunk) => !/^(polyfills|main|pages\/_app)$/.test(chunk.name),
      minSize: 20000,
      minRemainingSize: 0,
      minChunks: 1,
      maxAsyncRequests: 30,
      maxInitialRequests: 25,
      enforceSizeThreshold: 50000,
      cacheGroups: {
        defaultVendors: false,
        default: false,
        framework: {
          chunks: 'all',
          name: 'framework',
          test: /(?<!node_modules.*)[\\/]node_modules[\\/](react|react-dom|scheduler|prop-types|use-subscription)[\\/]/,
          priority: 40,
          enforce: true,
        },
        commons: {
          name: 'commons',
          minChunks: 1,
          priority: 20,
        },
      },
    }

So I moved the config over to my sample project and reproduced the error there: https://github.com/Qeldrona/prototype

If you comment out the web worker useEffect hook in index.js OR remove the commons object in next.config.js then npm run build will be successful. If you have them together the build will throw the error.

Alternatively, raising minChunks manually based on project size seems to also work. e.g. in our project 10 breaks but 50 compiles.

Saw this as well and reverted to 10.1 for the time being. Thanks for looking into it!

Through trial and error, the error goes away after i comment out a spread expression, i.e:

return { type: 'Message', ...options };

Cannot reproduce in the example though. That being said, we have a monorepo with typescript where we import the function that contains the spread from another package. I’ll try and set that up when i have the time, dropping a line in case someone finds it useful.

The fix is in the current canary branch and at least from my initial testing it appears to resolve the issue for us. Hope it does so for everyone else as well. I’ll be doing further testing and deploys to make sure but so far so good!

Sure, submitted https://github.com/vercel/next.js/issues/34064 with the repro.

On latest next 12 and the workaround doesn’t work for me…

@talaikis any chance you could share the whole snippet which fixes the issue?

config.optimization.splitChunks = { solution works for Next 12+, just build process is much longer and pages are much bigger now.

I am running into the same issue on build (works on dev) with Nextjs 12.0.2 for client side webworkers.

If a second worker imports the same file as the first one, build fails. If a worker imports file from external packages used somewhere else as well, build fails.

@Qeldrona It works - Size is roughly similar in my case but build time is x2

Just tried this on next@11.0.1-canary.5 and it is still an issue. I know that contained the PR fixing some other web worker issues so I just wanted to check on this one too.