[wp-trac] [WordPress Trac] #48154: Build Tools: Integrate DependencyExtractionWebpackPlugin in the JS build

[WordPress Trac]

#48154: Build Tools: Integrate DependencyExtractionWebpackPlugin in the JS build
-------------------------------------------------+-------------------------
 Reporter:  gziolo                               |       Owner:  gziolo
     Type:  enhancement                          |      Status:  reopened
 Priority:  normal                               |   Milestone:  5.4
Component:  Script Loader                        |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  dev-feedback needs-patch 2nd-        |     Focuses:  javascript
  opinion                                        |
-------------------------------------------------+-------------------------

Comment (by gziolo):

 Replying to [comment:23 azaozz]:
 > Looking more at the changes here, this is set as "Build/Test Tools" but
 in fact enhances/partially refactors how script-loader.php works. That's
 (mostly) OK when in /src, but perhaps not that good for /build (in
 production). If this was intended only for the source, this ticket need
 more work :)

 > - It's not a good idea to have a bunch of (around 80) files be included
 on each WP run. It's true, `include()` is pretty fast in PHP, but what's
 the purpose of including these files separately in production? What is
 fixed or enhanced by that? These files can be present in /src if need be,
 but should not exist in /build.

 You either load development or production version so it's half of the
 number you shared. I don't think I understand the concern you raise. It
 works exactly the same as all JavaScript files generated in the build
 step. Those asset files list all script dependencies which otherwise would
 have to be maintained manually. If we were to change how the /build is
 handled, it would have to change for JS files as well.

 > - In script-loader the version string is only used to "bust cache" when
 a js or css file changes between different WP versions. Having separate
 "cache-busting" strings for `*.js` and `*.min.js` doesn't make sense. In
 addition the current "cache-busting" strings seem needlessly long. Ideally
 the current WP version would be used when adding or changing a js or css
 file. This also removes the expectation that a particular file's version
 can be retrieved by looking at script-loader (that is incorrect in many
 cases). Alternatively the "cache-busting" (version) should be set to
 `false` which will use the current WP version.

 `*.js` and `*.min.js` have different content so they have different hash
 assigned. The way it works it allows for reusing the same cached file in
 the browser when its content doesn't change. It's a quite popular
 technique for ensuring that you never get a cached version when the
 content of the file changed.

 > - The addition of `assets` sub-directory in `wp-includes` seems a bit
 misleading/confusing. The name `assets` is widely used on the web, with
 different context. Best to rename it imho.

 What do you propose as an alternative?

 > Changing the component to script-loader as this is a
 refactoring/enhancement there. This will require "merging" all one-line
 files from `wp-includes/assets/dist` to `script-loader.php` when building
 (perhaps similarly to how the emoji code is handled).

 Is it really a concern to have multiple include files these days with all
 caching mechanism that PHP have baked in?

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