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

Build: Add new Webpack plugin to handle library default export #6935

merged 3 commits into from May 25, 2018


None yet
2 participants

gziolo commented May 24, 2018


Closes #6748.

Previously: #6584 (comment)

The intention with consuming from the WordPress npm organization packages is that each module would have itself exposed as an equivalent camel-case form as a property on window.wp. This already works well for most packages, allowing developers to use e.g. wp.i18n.__ (the __ named export from @wordpress/i18n).

However, for packages which have a default export, the usage is not as expected:

wp.domReady.default( function() {

Note the .default, which ideally should be omitted, calling instead as wp.domReady( fn ).

I played with the different approaches proposed in #6748 and ended up implementing a custom Webpack plugin, which works very similar to what libraryExport: 'default' does as explained in Webpack docs:

libraryExport: "default" - The default export of your entry point will be assigned to the library target:

// if your entry has a default export of `MyDefaultModule`
var MyDefaultModule = _entry_return_.default;

Plugin's implementation is based on the ExportPropertyMainTemplatePlugin core plugin. The only difference in here is that instead of applying this transformation to all entry points, we will be able to provide the list of chunks where this should be applied:

new LibraryExportDefaultPlugin( [ 'dom-ready' ].map( camelCaseDash ) )

How has this been tested?

Make sure npm run dev and npm run build work properly.

It should be possible to execute the following code on the JS console when running Gutenberg:

wp.domReady( () => {} );


  • My code is tested.
  • My code follows the WordPress code style.
  • My code follows the accessibility standards.
  • My code has proper inline documentation.

@gziolo gziolo requested review from aduth and youknowriad May 24, 2018

@gziolo gziolo self-assigned this May 24, 2018

@gziolo gziolo added this to the 3.0 milestone May 24, 2018

@gziolo gziolo referenced this pull request May 24, 2018


Deprecated: Introduce new module with depreaction util #6914

4 of 4 tasks complete

@gziolo gziolo requested a review from ntwb May 24, 2018


aduth approved these changes May 25, 2018

Looks (and works) great 👍

Unfortunate that we can't detect this automatically. Guessing that's impossible / prohibitively difficult to implement. At least for the time being, I'm more concerned with avoiding developers coming to expect the .default property to exist.

@aduth aduth merged commit de04b61 into master May 25, 2018

2 checks passed

codecov/project 46.21% (+0.08%) compared to 5ebefc3
continuous-integration/travis-ci/pr The Travis CI build passed

@gziolo gziolo deleted the add/library-export-default-plugin branch May 25, 2018

@Shelob9 Shelob9 referenced this pull request May 29, 2018


Packages: Publish all modules as independent npm packages #3955

19 of 19 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment