Nuxt.js: Client-mode builds should resolve the "pkg.module" field rather than "pkg.browser", for imported modules

Created on 4 Sep 2019  路  2Comments  路  Source: nuxt/nuxt.js

What problem does this feature solve?

The mysterious and ever elusive package.json file. For the context of this feature request there are three particular fields of interest

  • main: the primary entry point to a NodeJS module/program. Expected to be in a CommonJS (CJS) format (aka: using require()) since that is what NodeJS handles natively
  • browser: similar to main, but meant to be used client-side and consumed directly in the browser (aka: using <script> tag)
  • module: similar to the two above fields, but intended only to expose ESM (ECMAScript modules) rather than CJS (aka: using import)

While "module" is not part of the official NodeJS or npm spec, it is extremely widely used by package developers (Vue, Vuex, Angular, Vuetify) and is recognized by all major bundlers as part of their resolution algorithm (webpack, Rollup)

Defaulting to the "browser" field seems incorrect, since every Nuxt project will have a build system and therefor be ESM aware.

Similar to how the Nuxt webpack server config reprioritized modules, the same should be done for the webpack client config

What does the proposed changes look like?

/packages/webpack/src/config/server.js#L48
resolveConfig.resolve.mainFields = ['module', 'browser', 'main']

This feature request is available on Nuxt community (#c9728)
feature-request

Most helpful comment

Will look into this.

Currently we are using default mainFields of webpack which is 'browser', 'module', 'main' which should be most common used convention.

Your proposal will only affect libs who have both browser and module.
For the libs which have both browser and module bundle, if only difference between them is esm or commonjs, the webapck build should work same between browser and module , even in optimization like tree shaking.
But if the libs whose browser and module bundles are different, as libs in node_moudles won鈥檛 be transpiled by babel, this proposal may break their app.

As a quick solution of your requirement, I suggest using build.extend of nuxt.config to override client side mainFileds.

All 2 comments

Will look into this.

Currently we are using default mainFields of webpack which is 'browser', 'module', 'main' which should be most common used convention.

Your proposal will only affect libs who have both browser and module.
For the libs which have both browser and module bundle, if only difference between them is esm or commonjs, the webapck build should work same between browser and module , even in optimization like tree shaking.
But if the libs whose browser and module bundles are different, as libs in node_moudles won鈥檛 be transpiled by babel, this proposal may break their app.

As a quick solution of your requirement, I suggest using build.extend of nuxt.config to override client side mainFileds.

For the libs which have both browser and module bundle, if only difference between them is esm or commonjs

the more common scenario is that the browser bundle is not cjs but either (in webpack terms) "window" or "umd". if it was cjs it would just stick to using the regular "main" field.

As a quick solution of your requirement, I suggest using build.extend of nuxt.config to override client side mainFileds

yup, that is exactly what I'm doing today

Was this page helpful?
0 / 5 - 0 ratings

Related issues

nassimbenkirane picture nassimbenkirane  路  3Comments

bimohxh picture bimohxh  路  3Comments

VincentLoy picture VincentLoy  路  3Comments

gary149 picture gary149  路  3Comments

vadimsg picture vadimsg  路  3Comments