Open metasoarous opened 3 years ago
Def support smaller bundlesize, but fwiw the 140 kb bundlesize was just an arbitrary clean number that was just a small amount (10kb ish) larger than what it was earlier. The intent was so that something failed if it jumped too much while updated deps or whatever. (And on the odd occasion that I cleaned up a dep and bundlesize got smaller, I'd reduce the threshold to keep the CI failure similarly far away :) )
So in short, since it's already grown, it's equally valid just to bump the threshold and get back to green, and just watch it a bit more closely on future PRs. Whichever feels right!
Thanks for providing some additional insight into this @patcon.
@colinmegill I guess we should decide long term whether we want to continue with this, or set a fixed limit that we try to stay within. My inclination is towards the latter so that we don't add additional friction to staying on top of dep updates. That having been said, we can always use this as an opportunity to just go some house-keeping and try to get it back under 140k (such as #1107). For the participation client in particular, bundlesize is important to us. Thoughts?
Thanks again.
+1 to housekeeping! I feel bundlesize could be a good, user-centric lens to guide streamlining of client-participation :)
Expected behavior: Bundle size should be below 140kb.
Actual behavior: Currently at ~143kb; see bundlewatch results
Additional context: Not sure when/how this creaped up, or what the right solution is.
In GH: https://github.com/compdemocracy/polis/runs/3284694583?check_suite_focus=true
found on #1084