[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 azaozz):

 Replying to [comment:26 gziolo]:
 > 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.

 The main concern here is that this is an "architectural change" in the
 (built) application that is done to accommodate how some building tool(s)
 work and doesn't make sense for the application.

 Why would you want to split one file into 80 one-line files and then
 `require` them (or half of them) every time the app runs? There is some
 mild slowdown/increased use of resources on the server regardless of
 whether these files are used or not. What are the benefits for the built
 app?

 > If we were to change how the /build is handled, it would have to change
 for JS files as well.

 Sure, lets look at that too. IMHO it makes sense to optimize while
 building not "deoptimize" :)

 > `*.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.

 Right. The content (code) is formatted differently but as code it's
 exactly the same. However the file names are different. Switching from
 `*.js` to `*.min.js` will never use the non-minified version of the file.
 Since the code is exactly the same it seems to make sense to use the same
 "cache busting" string for both versions of the file. In reality it
 doesn't really matter, as long as there are new cache busting strings in
 new versions of WP.

 > It's a quite popular technique for ensuring that you never get a cached
 version when the content of the file changed.

 Hehe, yeah, that's the old old way to (attempt to) refresh network and
 browser caches. It still may fail in some cases, mostly for network
 caches, after all these years...

 Generally it doesn't matter what string is used. However using a "real"
 version or hash may eventually bring problems with some plugins expecting
 to be able to determine a particular dependency's version by using the
 cache busting string. This shouldn't be encouraged, if possible. Thinking
 that passing `false` may be a better option there, then the current WP
 version will be used. Or perhaps we can "hard-code" the current WP version
 at the time the file was last updated in core.

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

 It's not "huge" concern, but it still uses server resources. With
 WordPress' "footprint" that is still quite a lot. Thinking that a good
 "rule of thumb" would be to avoid that when there are no benefits for the
 (built) app.

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