Optimize webpack bundles #3457
Draft
Optimize webpack bundles #3457
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This was added in 30e0316, but these events have been supported in modern browsers for years by now. Also, the PR that added this polyfill (metabrainz#1858) already included a workaround that didn't require the events.
* All JS files referencing `ko` should be importing knockout at this point. * I didn't find any free references to the `ko` global in .tt files either.
It was already being loaded in the respective $entity/index.js files in most cases.
Also avoid loading the `CommonsImage` component entirely if disabled at the DBDefs level -- this just leads to pointless requests and page bloat.
It was already being loaded in the respective $entity/index.js files, except for genres, which is now fixed.
It's only used in the file it's defined in, so there's no need to expose it on there.
AFAICT, the only use of these rating macros was in root/medium/tracklist.tt. But the only use of *that*, in root/cdtoc/attach_list.tt, passed `hide_ratings = 1`.
This is used for event art too, and "load" makes it clearer what it's for.
1.5.1 uses an old version of clean-css which doesn't work in Node v23 (as it references the long-deprecated and now-removed `Util.isRegExp`).
The jed-data bundle basically just contained an object which the other language-specific bundles could import and extend. But it's not really needed, because we can just put the language-specific data into `GLOBAL_JS_NAMESPACE`. The other use of the jed-data module (which was the only file in the bundle) was to provide an "en" template that other languages' data could be based on, as well as serve as fallback data for the "en" case (since the `Jed` constructor still needs something to initialize it with). I've just renamed the file to jedDataTemplate.mjs and froze the exported object to make this remaining use case clearer.
I've removed code that's no longer used/needed and merged the loop-bindingHandler-specific code to where that's defined.
It doesn't seem to be referenced anywhere.
There are no longer any references to this.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Problem
We have a file, root/static/scripts/common.js, which is used as a Webpack entry point for code that gets run on every page. It bundles a ton of code which definitely doesn't need to run on every page. We have a similar one for edit pages.
The common-chunks bundle also includes too much code; we could allow more chunks to be duplicated in other bundles to reduce the size of common-chunks, and thus the amount of code that gets run on each page (at the cost of more files having to be downloaded/cached initially).
Solution
This mainly just adds additional entry points, or missing imports for the files that were listed in common.js, then removes common.js. I started something similar for edit.js but didn't finish it. Most of this code was started last year, but I lost motivation to finish it because the React migration would have improved a lot of these issues too (by deleting a lot of the code being run). Since that's taking too long, I decided to submit it anyway (as it will still be useful in the long run).
Testing
Just browsing/using the affected pages locally.