Next.js: After upgrading to to 9.5.2, client bundle includes unnecessary browser-node-polyfills

Created on 17 Aug 2020  ·  8Comments  ·  Source: vercel/next.js

Bug report

Describe the bug

After upgrading to [email protected], client bundle includes browser polyfils for Node.js, probably related to #16022.

As far as I can tell, no code relies on these modules, because doing

          delete config.resolve.alias.crypto;
          delete config.resolve.alias.stream;
          delete config.resolve.alias.path;
          delete config.resolve.alias.buffer;
          delete config.resolve.alias.vm;

in next.config.js removes the modules from the bundle, but the code still works.

To Reproduce

Steps to reproduce the behavior, please provide code snippets or a repository:

  1. Upgrade to next 9.5.2
  2. Bundle your code
  3. Inspect the output

I realise that this will not be easy to debug, since it probably is related to our setup, which is closed source (sorry).

Expected behavior

Unnecessary browser node polyfills should not be in the bundle

Screenshots

Screenshot 2020-08-17 at 14 59 16

System information

  • OS:macOS
  • Version of Next.js: 9.5.2
  • Version of Node.js: 12.18.3

Additional context

My best guess is that some code only running on the server causes this to be bundled, even though it is not used on the client.

Any help with further debugging would be awesome, just knowing why these are ending up being a part of the bundle. What dependency triggers these to be bundled.

bug 2 p0

Most helpful comment

I can confirm this. Our numbers under "First Load JS" grew from around 100KB to more than 300KB per page! Our application uses sockjs-client. If I disable this import, the sizes go back back to normal.

I was able to track this down to 9.5.2-canary.10 (with 9.5.2-canary.9, everything was still OK), so I guess @tbergq is right that it must have something to do with #16022

Adding the delete lines to next.config.js as @tbergq suggested actually resolves the problem. Thanks for the workaround!

Our application is open-source. It can be found here:
https://github.com/steep-wms/steep/tree/master/ui

Let me know if I should try to create a minimal example.

All 8 comments

I can confirm this. Our numbers under "First Load JS" grew from around 100KB to more than 300KB per page! Our application uses sockjs-client. If I disable this import, the sizes go back back to normal.

I was able to track this down to 9.5.2-canary.10 (with 9.5.2-canary.9, everything was still OK), so I guess @tbergq is right that it must have something to do with #16022

Adding the delete lines to next.config.js as @tbergq suggested actually resolves the problem. Thanks for the workaround!

Our application is open-source. It can be found here:
https://github.com/steep-wms/steep/tree/master/ui

Let me know if I should try to create a minimal example.

A minimal reproduction would certainly be helpful

A minimal reproduction would certainly be helpful

Yeah, I do understand that, however, I have no idea where to begin, since I don't even know which dependency triggers this to be bundled 🙈

Had a look at @michel-kraemer's case sockjs-client/lib/utils/random.js includes require('crypto'), potentially this was shaken later on by webpack previously. Checking with @sokra to see if this can be fixed without removing the aliases in webpack 4 envs.

Overall this library that you're depending on (sockjs-client) was not meant to be shipped to the browser if it includes crypto in that way and webpack made it accidentally work

Thanks for looking into this. Here's the minimal example:
https://github.com/michel-kraemer/test-nextjs-sockjs-client

Just run npm rund build. The root page should be about 280 KB large.

According to their README, sockjs-client is supposed to run in the browser (and I've been using it for years, actually) 🤷‍♂️ Do you think it makes sense to open an issue there as well?

Ah, I see. The library makes use of this feature to resolve the crypto module to their own implementation:
https://github.com/defunctzombie/package-browser-field-spec#replace-specific-files---advanced
(cf. https://webpack.js.org/configuration/resolve/#resolvealiasfields)

See here:
https://github.com/sockjs/sockjs-client/blob/master/package.json#L11

I guess, webpack does not use the alias from the package.json anymore if it already has one.

Thanks for investigating, yeah that seems to be the issue, discussing with @sokra if this is fixable

I managed to find out the reason that we got these node-polyfills bundled.

We have a dependency that depends on seedrandom.

That package also sets browser: {crypto: false} in package json

If I set this dependency as external, node-polyfills are no longer bundled.

So the issue is the same as @michel-kraemer is describing.

Was this page helpful?
0 / 5 - 0 ratings