[wp-trac] [WordPress Trac] #40894: Use Webpack instead of Browserify for build process

[WordPress Trac]

#40894: Use Webpack instead of Browserify for build process
------------------------------+------------------------------
 Reporter:  adamsilverstein   |       Owner:  adamsilverstein
     Type:  enhancement       |      Status:  assigned
 Priority:  normal            |   Milestone:  4.9
Component:  Build/Test Tools  |     Version:  3.5
 Severity:  normal            |  Resolution:
 Keywords:  has-patch commit  |     Focuses:  javascript
------------------------------+------------------------------

Comment (by aduth):

 A higher level question:

 - Maybe not in the scope of what's intended here (simply replacing
 Browserify), but eventually what role would Webpack seek to serve? For
 example, the Grunt task for uglification is one which Webpack has built-in
 support (`webpack.optimize.OptimizeJsPlugin`). The devil's advocate
 question is: if it's just for basic bundling, are we gaining much over
 Browserify (+Babelify)?

 A couple thoughts on the configuration:

 - At some point if we start to observe significant overlap between
 development and production configurations, we might want a more scalable
 approach to sharing common properties (like a common configuration).
 Conversely, if this is not something we want to aim for early on, we may
 not even need the file split right now. Gutenberg, for example, has a
 single `webpack.config.js` which switches on the `process.env.NODE_ENV` to
 add/modify configuration values. This could help with avoiding redundancy
 on assigning `mediaConfig`.
 - Should `watch: true` be assigned into the configuration from
 `Gruntfile.js`, or does that make more sense within the configuration
 itself?
 - We specify `stats` dependant on the `process.env.NODE_ENV` but it
 doesn't appear we set this `NODE_ENV` anywhere, so it seems unnecessary.
 And even if it did work as expected, would we want nothing to be output
 for production builds?

 A few minor styling quibbles (in Webpack config files):

 - Should we bother with space aligning variable and object property
 assignment? Especially with comma-delimited variable declarations, it
 makes the incorrect assumption that a tab occupies four spaces (in Trac
 patch, it's obvious with the misalignment since it previews tabs at 8
 spaces). Also that we have two spaces following the longest variable name
 in the respective Webpack configurations.
 - Should be spaces between array square brackets (`mediaBuilds`) and in
 require calls, and not after function keyword
 - `module.exports` object should be concluded with a semi-colon.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/40894#comment:23>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform