Nwb: UMD build undefined when no default export

Created on 8 Dec 2017  路  2Comments  路  Source: insin/nwb

This issue is a:

  • Bug report

I have a vanilla JS web component that defines named exports in src/index.js like such:

export {  a, b, c }

This leads to the umd global variable being undefined.

If changing above to a default export

export default {  a, b, c }

things work for umd, and the umd variable is an object as expected { a, b, c }

I've read that nwb recently dropped the need to address default exports via .default.
Perhaps that change has to be skipped if named exports are present?

Is the version of nwb you're using installed globally or locally?
global

Which versions of Node.js, npm and nwb are you using (if using it globally)?
node v8.9.1, [email protected], [email protected]

bug enhancement

Most helpful comment

I've created a Webpack feature request for this, as it would be nice for everyone if output.libraryExport automatically exported the default export when a library's entry module is using ES2015 modules instead of having to configure it:

webpack/webpack#6097

Faiing that, alternative courses of action are:

  • Add support for some new configuration under the umd config object in nwb.config.js to tell nwb how you're exporting your library (low effort)

    • e.g. umd.exports, which can be default or named and is used to set Webpack's output.libraryExport appropriately

    • e.g. umd.entry, which allows you to provide a separate entry module for UMD builds which must export default

    • Add comments to src/index.js in the react-component and web-module project templates to document that you must export default or the UMD build won't work by default, with directions to the appropriate configuration options if you'd rather use named exports because default.

  • Switch nwb over to Rollup for UMD builds (high effort, need to investigate Rollup properly and its plugin ecosystem for parity with features available in current Webpack build, such as aliases and defining replacements of certain expressions)

It's not ideal, but in the meantime you should be able to use webpack.extra or webpack.config() in nwb.config.js to override output.libraryExport when performing a UMD build.

All 2 comments

I've created a Webpack feature request for this, as it would be nice for everyone if output.libraryExport automatically exported the default export when a library's entry module is using ES2015 modules instead of having to configure it:

webpack/webpack#6097

Faiing that, alternative courses of action are:

  • Add support for some new configuration under the umd config object in nwb.config.js to tell nwb how you're exporting your library (low effort)

    • e.g. umd.exports, which can be default or named and is used to set Webpack's output.libraryExport appropriately

    • e.g. umd.entry, which allows you to provide a separate entry module for UMD builds which must export default

    • Add comments to src/index.js in the react-component and web-module project templates to document that you must export default or the UMD build won't work by default, with directions to the appropriate configuration options if you'd rather use named exports because default.

  • Switch nwb over to Rollup for UMD builds (high effort, need to investigate Rollup properly and its plugin ecosystem for parity with features available in current Webpack build, such as aliases and defining replacements of certain expressions)

It's not ideal, but in the meantime you should be able to use webpack.extra or webpack.config() in nwb.config.js to override output.libraryExport when performing a UMD build.

Thanks for the comments on this. I found myself in a similar situation and used the webpack.config() option to solve my problem.

However, FWIW, from my perspective, a umd.entry file would be ideal, as it would provide me a separate place to define my UMD build.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

empz picture empz  路  4Comments

insin picture insin  路  5Comments

pedrocostadev picture pedrocostadev  路  5Comments

AquiGorka picture AquiGorka  路  3Comments

LeoDT picture LeoDT  路  5Comments