Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add bundlewatch/bundlewatch to dev dependencies. #819

Merged
merged 3 commits into from
Jul 7, 2021
Merged

Conversation

tomalec
Copy link
Member

@tomalec tomalec commented Jun 24, 2021

Changes proposed in this Pull Request:

Add bundlewatch/bundlewatch to dev dependencies.
to monitor our progress in reducing bundle size.

Fixes #818.

Screenshots:

bundlewatch

Detailed test instructions:

  1. check out this branch
  2. npm install
  3. npx bundlewatch
  4. Click on the link for the detailed report

To be done:

Changelog entry

Tweak - Add bundlewatch to monitor bundle size in GitHub PRs.

to monitor our progress in reducing bundle size.

Fixes #818.
@tomalec tomalec self-assigned this Jun 24, 2021
@tomalec tomalec requested a review from a team June 24, 2021 11:09
@tomalec
Copy link
Member Author

tomalec commented Jul 2, 2021

Small research for bundlewatch usage in Woo

gutenberg-products-block repo tried it then removed it over a year ago in favor of custom GH workflow, for the following reasons:

  • We get inline feedback (as a comment) in the pull on any size changes.

Personally, I find it a disadvantage:

  • It comments only the initial PR post (commits set), so we don't get bundle size after commits that may follow during the review. In GLA we tend to make quite a number of commits after the initial PR.
  • This way we cannot block the merge if we enforce a bundle size budget
  • This compares overall changes against the base branch for the pull (which we weren't getting with bundlewatch).

If I understood the docs correctly, the current version of bundlewatch can pick the PR base from Travis and compare against it.

  • A list of all files and their changes is shown in a collapsed list in the posted comment. With bundlewatch, their linking system was broken, so if we wanted that granularity we had to go into the travis-ci job (which only showed us the sizes, not the difference from the base branch).

For my local test, linking was working fine. Also, I think in GLA we do not have so many bundles, so hopefully, it's not a big issue for us.

  • Removes the time for the bundlewatch checks from the linting travis job (not a huge difference but helps).

If we're not experiencing hitting Travis limit yet, maybe we can still use it, and worry about it once we start exceeding it.


woocommerce.com is using bundlesize the ancestor of bundlewatch


In woocommerce-admin some efforts were made to try to setup a custom github action, but it seems it wasn't finished
https://github.com/woocommerce/woocommerce-admin/actions/workflows/bundle-size.yml

@tomalec
Copy link
Member Author

tomalec commented Jul 2, 2021

I think the above gives us precedence to trust the bundlewatch enough to authorize it, WDYT @jconroy?

@ecgan
Copy link
Member

ecgan commented Jul 5, 2021

@tomalec , I love the analysis you posted, good stuff 🙂 👍

woocommerce.com is using bundlesize the ancestor of bundlewatch

That got me curious. I looked into both bundlesize and bundlewatch, and it seems like bundlesize is much more popular than bundlewatch.

I tried to google for comparisons between the two to find out which is better, but there isn't any helpful info on this.

So my question here is: given its popularity, should we consider using bundlesize instead of bundlewatch? Why or why not? 🤔

@tomalec
Copy link
Member Author

tomalec commented Jul 5, 2021

[…] given its popularity, should we consider using bundlesize instead of bundlewatch? Why or why not? thinking

AFAIK bundlewatch is kindof community fork of bundlesize, as -size got somewhat unmaintained.
You can check bundlewatch'es list of reasons

  • Bundlesize has entered maintenance mode and pull requests are left hanging, so we wanted to reboot the community through creating BundleWatch

Check the latest release dates:

@jconroy
Copy link
Member

jconroy commented Jul 6, 2021

Thanks @tomalec for looking into this and especially for searching around in this comment to look for existing usages within Woo/A8C

Authorize the app, to enable GitHub check

Screen Shot 2021-07-06 at 9 48 53 pm

I think both BundleSize and BundleWatch area already approved for the Woo org.

I like the idea of using Actions (especially now the repo is public) - we'll likely use more - but happy for us to try BundleWatch and revisit it and see if the previous areas of concern have improved.

I leave @ecgan and @eason9487 to comment/feedback/review before merging

@ecgan
Copy link
Member

ecgan commented Jul 6, 2021

@tomalec ,

You can check bundlewatch'es list of reasons

Hey, thanks for that! I didn't notice that. Google search should have shown me that 😆

Check the latest release dates:

And I did not notice that too. I did notice that on https://www.npmjs.com/package/bundlesize, the latest release is 0.18.1 and it is published 6 months ago. I looked into the repo and the release is related to axios security vulnerability issue (siddharthkp/bundlesize#369), and from that issue I notice there is another repo https://github.com/siddharthkp/bundlesize2, which does not seem to be very active either.

With all the above said (including your good findings), I think I would lean towards bundlewatch now. Just hoping that it can do everything that bundlesize does, and there are good documentations that can be easily googled. 😄

Copy link
Member

@ecgan ecgan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tested as per instruction, working good, LGTM 👍

package.json Outdated
Comment on lines 94 to 117
"bundlewatch": {
"files": [
{
"path": "./js/build/*.js",
"maxSize": "2 kB"
},
{
"path": "./js/build/index.js",
"maxSize": "1 mB"
},
{
"path": "./js/build/*.css",
"maxSize": "1 kB"
},
{
"path": "./js/build/index.css",
"maxSize": "8 kB"
},
{
"path": "./google-listings-and-ads.zip",
"maxSize": "12 mB",
"compression": "none"
}
]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💅 Personally I would prefer to put these into a separate file like .bundlewatch.config.js and have bundlewatch to automatically read the file, unfortunately currently bundlewatch requires us to specify it in the command line like bundlewatch --config .bundlewatch.config.js (see the documentation), which is an unnecessary friction in my opinion. Hopefully they can support that in the future.

So with that said, good to have this bundlewatch section here in this package.json so that we can just run npx bundlewatch. 👍

@tomalec
Copy link
Member Author

tomalec commented Jul 7, 2021

I tried adding GitHub action for bundlewatch, for example below.
I tried to make it run for every push, not just initial PR.
But there is a bug in bundlewatch <- ci-env bundlewatch/bundlewatch#422
We could hard-code it to compare only against trunk and develop, but in my opinion comparing against base makes the most sense.

So I fall back to running it on Travis-CI, where it works out of the box.

name: bundlewatch

on: [push]

jobs:
  build:
    if: "!contains(github.event.commits[0].message, '[skip ci]')"
    runs-on: ubuntu-latest
    timeout-minutes: 10

    steps:
    - uses: actions/checkout@v2

    - name: Install npm dependencies
      run: npm ci

    - name: Build
      run: npm run build

    - name: Run bundlewatch
      run: npx bundlewatch
      env:
        BUNDLEWATCH_GITHUB_TOKEN: ${{ secrets.BUNDLEWATCH_GITHUB_TOKEN }}
        CI_COMMIT_SHA: ${{ github.event.pull_request.head.sha }}
        CI_BRANCH_BASE: ${{ github.base_ref || 'trunk' }}

tomalec added a commit that referenced this pull request Jul 7, 2021
GitHub Actions are a bit too problematic, see
#819 (comment)
GitHub Actions are a bit too problematic, see
#819 (comment)

Remove redundant `npm ci` from `Coding standard check`.
Increase maxSizes of bundles.
@tomalec tomalec merged commit 172096f into trunk Jul 7, 2021
@tomalec tomalec deleted the add/818-bundlewatch branch July 7, 2021 23:04
Comment on lines +118 to +120
"ci": {
"trackBranches": ["trunk", "develop"]
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@tomalec , just noticed this, really minor nitpick: the three lines here are using space indentation instead of tabs like other lines. 😄

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd address it in #869

tomalec added a commit that referenced this pull request Jul 8, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Monitor bundle size changes for PRs
3 participants