A while ago we decided to automatically bump our bundle size limits on a weekly basis, with the main objective of avoiding having to bump limits on PRs that didn't cause a lot of size increase on their own, but brought existing limits just over the brink. While the new approach fixes this in 99% of the cases, it also makes us much less aware of larger increases because they still fall under the weekly bumped limit.
We talked about this issue and decided that
- We don't want to resort to the old behaviour since it brought indeed friction
- Instead, we want to go with a per-PR/size-diff based approach:
- Check delta of size increase that the specific PR causes
- Fail CI job if size increase is larger than 0.5KB for gzipped bundles. Don't take uncompressed bundles into consideration.
- Have users apply a label (e.g. "Increases bundle size"), or alternatively a comment that reruns the CI job so that it passes. (The advantage of the label is that we can filter on size-increasing PRs easier but it's not a must-do).
- Remove the weekly bumping and the actual size limits. We of course still want to report the overall bundle size (on every PR and on every GH release) but since we move to a diff-based limiting approach, there's no point anymore for overall limits
h/t @nicohrubec for suggesting the per-PR idea!
A while ago we decided to automatically bump our bundle size limits on a weekly basis, with the main objective of avoiding having to bump limits on PRs that didn't cause a lot of size increase on their own, but brought existing limits just over the brink. While the new approach fixes this in 99% of the cases, it also makes us much less aware of larger increases because they still fall under the weekly bumped limit.
We talked about this issue and decided that
h/t @nicohrubec for suggesting the per-PR idea!