Description
Details
| Project | Branch | Lines +/- | Subject | |
|---|---|---|---|---|
| mediawiki/extensions/MobileFrontend | master | +1 K -3 | Hygiene: add gzipped minified bundle size tests |
Event Timeline
Change 455243 had a related patch set uploaded (by Niedzielski; owner: Stephen Niedzielski):
[mediawiki/extensions/MobileFrontend@master] Hygiene: add gzipped minified bundle size tests
@ovasileva /cc @Jdlrobson, sorry I needed to work on this unplanned task to report on requested sizing differences in T199452. Both this task and T199452 are ready for review.
Change 455243 merged by jenkins-bot:
[mediawiki/extensions/MobileFrontend@master] Hygiene: add gzipped minified bundle size tests
Tested locally, works as expected. After a couple changes to the mobile.startup.js script started to fail that file size exceed the max size.
Are there not better ways to track changes to the filesizes, e.g. a warning comment added to the patch like is done with code coverage dropping in some repos? This makes rebasing in MF (which is already very fiddly) even harder.
It can be run with warning code rather than error code, however we intentionally pin it to the current code value size, so that we are mindful of code changes on every patch (and whether those are desirable/acceptable). This is intentionally fiddly and has prevented a few accidental bumps in size due to badly managed webpack. Note, as we stablise this code and reduce number of modules, I expect this to become less fiddly.
I think for editing code, that's not on the critical path you might want to relax the bundle sizes to give you more leeway e.g. (kb rather than byte precision).
Note, there are 2 places we measure bundle sizes - via bundlesize and webpack. Personally I am not a fan of the webpack config bundle (which is more prone to change) although not strongly opposed to (although I know Stephen finds it important). Maybe we could consider removing those values to reduce friction?
Note, there are 2 places we measure bundle sizes - via bundlesize and webpack. Personally I am not a fan of the webpack config bundle (which is more prone to change) although not strongly opposed to (although I know Stephen finds it important).
Just wanted to chime in that I think the bundlesize tests are also important. I'd be fine with loosening the Webpack performance checks if they're blocking progress.