github / webpack-bundlesize-compare-action

A github action that outputs bundlesize comparison tables for pull requests

Webpack bundlesize compare action

An action that compares 2 webpack compilation stats files, and comments on the PR with a description of the difference

How to use it

In your application, ensure you output the stats.json, from `BundleAnalyzerPlugin'

// webpack.config.js
const {BundleAnalyzerPlugin} = require('webpack-bundle-analyzer')

// optionally you can also output compressed/gzipped stats. Requires a version >=1.1.0
const CompressionPlugin = require('compression-webpack-plugin')

module.exports = {
  plugins: [
    ...plugins,
    // not required
    new CompressionPlugin(),

    // required
    new BundleAnalyzerPlugin({
      // generate the stats.json file
      generateStatsFile: true
    })
  ]
}

Then, in your action configuration, build both the head and the branch (in any way you see fit) and pass paths to the stats.json files as inputs ot this action

# .github/workflows/bundlesize-compare.yml

on:
  # this action will error unless run in a pr context
  pull_request:
  pull_request_target:

jobs:
  # Build current and upload stats.json
  # You may replace this with your own build method. All that
  # is required is that the stats.json be an artifact
  build-head:
    name: 'Build head'
    runs-on: ubuntu-latest
    permissions:
      contents: read
    steps:
      - uses: actions/checkout@v2
        with:
          ref: ${{github.event.pull_request.head.ref}}
      - name: Install dependencies
        run: npm ci
      - name: Build
        run: npm run build
      - name: Upload stats.json
        uses: actions/upload-artifact@v3
        with:
          name: head-stats
          path: ./dist/stats.json

  # Build base for comparison and upload stats.json
  # You may replace this with your own build method. All that
  # is required is that the stats.json be an artifact
  build-base:
    name: 'Build base'
    runs-on: ubuntu-latest
    permissions:
      contents: read
    steps:
      - uses: actions/checkout@v2
        with:
          ref: ${{ github.base_ref }}
      - name: Install dependencies
        run: npm ci
      - name: Build
        run: npm run build
      - name: Upload stats.json
        uses: actions/upload-artifact@v3
        with:
          name: base-stats
          path: ./dist/stats.json

  # run the action against the stats.json files
  compare:
    name: 'Compare base & head bundle sizes'
    runs-on: ubuntu-latest
    needs: [build-base, build-head]
    permissions:
      pull-requests: write
    steps:
      - uses: actions/download-artifact@v3
      - uses: github/[email protected]
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}
          current-stats-json-path: ./head-stats/stats.json
          base-stats-json-path: ./base-stats/stats.json

This action requires the write permission for the permissions.pull-requests scope.

Options

name	description	required	type
current-stats-json-path	The path to the current stats.json file	true	string
base-stats-json-path	The path to the base stats.json file	true	string
github-token	The Github token	true	string
title	An optional addition to the title, which also helps key comments, useful if running more than 1 copy of this action	false	string

| describe-assets | Option for asset description output. One of "all" (default), "changed-only", or "none". | false | string |

Example PR Comment

#50 (comment)

webpack-bundlesize-compare-action's Issues

Webpack Bundle Compression Best Practices

Hi! Thank you so much for this action, I'm trying to set it up but am finding that the upload artifact stage can be extremely slow, especially for a 90mb stats.json file. Are there some best practices I should be following that I'm not?

I see an issue on the upload artifact repo saying "it's too slow," but maybe I should cache this artifact instead? Another issue I'm running into is that I'm trying to integrate this into a gatsby project, which is very "plugin-driven." I can add a webpack compression plugin, but it won't necessarily compress the stats.json file.

Branch Protections Audit - 2022-10-05T18-41-55-524

Action Items

This repo has been audited as a production component. Please respond in 4 weeks.

This repo was found missing required branch protections:

{
  "dismiss_stale_pr_reviews": {
    "error_message": "__required_pull_request_reviews.dismiss_stale_reviews__ Expected dismissal of stale PR approvals, found false.",
    "expected": true,
    "actual": false
  },
  "enforce_admins": {
    "error_message": "__enforce_admins__ Admins should not be allowed to bypass protections.",
    "expected": true,
    "actual": false
  }
}

If this audit is incorrect, or this repo does not need the outlined branch protections please file for an exception here.

• NOTE, dismiss_stale_pr_reviews is not yet mandatory for this repository, but will be in 5 weeks.

What is this, and why am I just now finding out about this?

See this engineering discussion for more information.

Ability to fail the CI if the percentage increase

I am trying to see if there is a possibility for CI to fail if the percentage increase is more than a threshold we have specified in the configuration. Is it something in pipiline, if not i can try to work on this one

Not sure this requires BundleAnalyzerPlugin

I might be missing something here, but I don't think this requires BundleAnalyzerPlugin at all, at least in recent versions of webpack. It looked to me like the output you get from generateStatsFile: true is the same as you get from running webpack with the --json flag.

Also, I believe when using the config described in the README, your job will actually hang forever, as BundleAnalyzerPlugin without analyzerMode: "disabled" will start an HTTP server that won't exit without user interaction. See:

webpack-contrib/webpack-bundle-analyzer#614

Fails to update existing comment

Hi! I’m using this workflow on a repository I help maintain, and it seems to be repeatedly creating a new PR comment instead of updating the existing one: actualbudget/actual#1122

It might be relevant that I’m running this as a pull_request_target workflow and the PR in question comes from a fork.

Workflow file: https://github.com/actualbudget/actual/blob/1bc988d9d168b56b6ef310173b492f0f8c2559ed/.github/workflows/size-compare.yml

Ignore hash in processed filename

Consider the attached screenshot from the action, where app-[hash].js has been removed but a new app-[hash].js has been added. In reality, these are actually the same file for comparison but have a slightly different hash for cache-busting purposes.

Would it be more true to simply move this down to the Smaller section and render a delta?

should truncate output if it's too long

Remove changeset output?

#155 added an file by file change analysis.

It seems this might be a bit too much output, and doesn't actually describe the relative impact on bundle so much as the change in file size.

Maybe we can truncate this to the 5 or so biggest changes, but does it provide the value intended?

not working

Show diff of initial chunks (in addition to total)

It'd be useful to see the change in the total initial bundle size (sum of all initial chunks) in addition to the total bundle. Webpack provides this per chunk with the initial boolean field. I might take a stab at this :)

Comment incorrectly reports no change

Thanks for publishing this action. Unfortunately, it doesn't seem to be working for me, I generated 2 stats files from different commits, but the comment on the PR says there is no change. Here is a partial diff between the two stat files:

-    "label": "main.ef4c6927.js",
+    "label": "main.1baa3a0e.js",
     "isAsset": true,
-    "statSize": 9680463.559999999,
-    "parsedSize": 3571859,
-    "gzipSize": 1026459,
+    "statSize": 9813627.559999999,
+    "parsedSize": 3610758,
+    "gzipSize": 1039000,

You can see the new main bundle is ~39k larger. Any idea what I might be doing wrong? I've included my full workflow below.

jobs:
  main-bundle-stats:
    name: Calculate main bundle stats
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
        with:
          ref: e2e1a19e6f4c5e43d2ed84167317c679099093c1 # only for testing purposes
        # with:
        # ref: ${{ github.base_ref }}
      - uses: actions/setup-node@v3
        with:
          node-version: 18
          cache: "yarn"
      - run: yarn install --frozen-lockfile
      - run: yarn build:analyze:json
      - name: Upload main-bundle-stats.json
        uses: actions/upload-artifact@v3
        with:
          name: main-bundle-stats.json
          path: ./dist/report.json

  head-bundle-stats:
    name: Calculate head bundle stats
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: 18
          cache: "yarn"
      - run: yarn install --frozen-lockfile
      - run: yarn build:analyze:json
      - name: Upload main-bundle-stats.json
        uses: actions/upload-artifact@v3
        with:
          name: head-bundle-stats.json
          path: ./dist/report.json

  report-bundle-size:
    name: Report bundle size difference
    runs-on: ubuntu-latest
    needs: [main-bundle-stats, head-bundle-stats]
    permissions:
      pull-requests: write
    steps:
      - uses: actions/download-artifact@v3
      - uses: github/webpack-bundlesize-compare-action@v1
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}
          current-stats-json-path: ./head-bundle-stats.json
          base-stats-json-path: ./main-bundle-stats.json

Intermittent failures updating message

About 25% of the time I'm noticing failures that I believe are calling GitHub apis.

Output:

Run github/[email protected]
  with:
    github-token: ***
    current-stats-json-path: ./build-stats/stats.json
    base-stats-json-path: ./base-build-stats/stats.json
Error: We couldn't respond to your request in time. Sorry about that. Please try resubmitting your request and contact us if the problem persists.

I've also seen Error: Server Error with no more additional details. Any idea what's causing this? Perhaps adding retry if the api is flakey?

Add GZIP data to tables, if gzipped

This might require webpack to pre-compress assets via something like compression-webpack-plugin pre to running bundle analyzer, but should provide another view into the bundle that's valuable to devs

readme example pointing to v1 of this action that does not support gzipped stats

the readme has instructions on enabling bundled gzipped stats with the compression plugin which is great.

after following the instructions I was still not getting the gzipped bundled stats.

I looked at the internals of this GH action to determine whether there's a bug.

from what I could tell by looking at the internals and my stats.json I should have been seeing the bundled gzipped stats.

eventually I looked at my GH workflow configuration which I copy-pasted from the README of this repo.

I noticed that it's pointing to v1 release of this repo which I suspect did not support the bundled gzip stats yet.

I managed to get the gzipped bundle stats by setting the ref to v1.4.0.

this is an issue to support a case for updating that ref so that it's consistent with the rest of the instructions.

or maybe remove ref altogether so that it defaults to using main branch.

I leave it up to you, thanks!

Open source action

https://github.com/github/open-source-releases

Why open source this?

• there's nothing that shouldn't be open sourced here
• a public repo allows us to publish to the actions marketplace, and makes updating/using easier, since there's no need to clone manually

Documentation update

Thanks for sharing this action. I have setup this action in our own workflow and it works as advertised.

As far as I can tell the instructions in the README are not entirely up to date. They refer to the repo being private, which is no longer the case, mentions steps like setup-node which does not seem to be necessary etc. There may also be an issue with compression and versioning as mentioned in #169

Are you interested in a PR with updates to address these issues?

Add describe for getting gzip describe in total

In Common total hard to understand how I can get gzip total. After couple hours I could understand what for getting gzip size describe I must compress all my files with compression-webpack-plugin. I don't have permission in your repository and can't create PR, but pls add help describe for other people

example from readme which I created but cannot create PR:

In your application, if you want to add gzip size in total, you will need to create gzip files from your project.

For example, you should add minRatio: Infinity in compression-webpack-plugin for get it because default value for minRatio: 0.8

// webpack.config.js
const {BundleAnalyzerPlugin} = require('webpack-bundle-analyzer')

// optionally you can also output compressed/gzipped stats. Requires a version >=1.1.0
const CompressionPlugin = require('compression-webpack-plugin')

module.exports = {
  plugins: [
    ...plugins,
    // not required
      new CompressionPlugin({
          test: /\.(js|css|json)(\?.*)?$/i,
          algorithm: 'gzip',
          minRatio: Infinity,
      }),

    // required
    new BundleAnalyzerPlugin({
      // generate the stats.json file
      generateStatsFile: true
      
    })
  ]
}

Increase Fidelity of metrics

We should track more significantly than just `1.3MB

`

Ideally, we'd keep 4 digits around, to help differentiate between small changes, and always format to a specific number of digits (even if 0s)