Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Server build prefers main over module in webpack resolve.mainFields #9323

Closed
elado opened this issue Nov 5, 2019 · 5 comments
Closed

Server build prefers main over module in webpack resolve.mainFields #9323

elado opened this issue Nov 5, 2019 · 5 comments

Comments

@elado
Copy link

elado commented Nov 5, 2019

Bug report[?]

Describe the bug

Webpack's default resolve.mainFields are:

https://webpack.js.org/configuration/resolve/#resolvemainfields

server = ['module', 'main']
browser = ['browser', 'module', 'main']

But next's:

mainFields: isServer ? ['main', 'module'] : ['browser', 'module', 'main'],

https://github.com/zeit/next.js/blob/8e62c9b688aa7a92e339b728237e8c63ec31f1b5/packages/next/build/webpack-config.ts#L219

The server build prefers main over module which may lead to unexpected results (for example, when having a package whose main points to ES5+CJS source but module points to ESNext+ESM).

To Reproduce

Have a package with module field that points to a different source than main, in server build it prefers the main.

Expected behavior

Prefer module over main in server build. Or, remove this setting completely and use webpack's default.

@elado elado changed the title Server mainFields are flipped? Server build prefers main over module in mainFields Nov 5, 2019
@elado elado changed the title Server build prefers main over module in mainFields Server build prefers main over module in webpack resolve.mainFields Nov 5, 2019
@macrozone
Copy link

macrozone commented Nov 6, 2019

bam! also ran into that one some days ago and it drove me crazy!

maybe there was a problem with some node packages? But i think in a project like next, that runs code isomorphic in server and client, its a bad idea to resolve packages differently, so this has to be changed.

Edit: changing it did not solve my issue, though. But something with the webpack config seems to be odd in nextjs

@elado
Copy link
Author

elado commented Nov 7, 2019

Indeed, an override not working as expected. With this next.config.js:

module.exports = {
  webpack: (config, { isServer }) => {
    return {
      ...config,
      resolve: {
        ...config.resolve,
        mainFields: isServer ? ['module', 'main'] : ['browser', 'module', 'main'],
      },
    }
  },
};

I believe server builds runs purely on node and use externals on all dependencies, which make them load with native require that goes to main.

I ended up pointing my main to what module had because everything goes through webpack anyway and I'm not planning on using that package in other contexts (e.g. pure node scripts).

@Timer
Copy link
Member

Timer commented Nov 9, 2019

It's very common that browser-only code is shipped under the module key in package.json.

We've tried to change this before and it ends up breaking more cases than it fixes.

We're going to leave this option as-is. If you really need it overridden, you can manually do it like you mentioned above.

@Timer Timer closed this as completed Nov 9, 2019
@elado
Copy link
Author

elado commented Nov 10, 2019

@Timer, preferring module over main in server builds is webpack’s default, so it means that many packages would break there, but I haven’t really seen this case. I haven’t encountered packages using module for browser only code, as this is browser field role (doesn’t mean it doesn’t exists, but it’s probably not very common).

As a side note, even with my workaround, the way next runs the code in server prevents from module to be used. From my understanding it keeps all dependencies as externals and runs code in standard node, which uses require and goes to main. I haven’t dug too deep but seems like module isn’t working on server builds at all.

@balazsorban44
Copy link
Member

This issue has been automatically locked due to no recent activity. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.

@vercel vercel locked as resolved and limited conversation to collaborators Jan 30, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants