chore: bundle size statistics

[levithomason]

This PR uses webpack to compute bundle size for individual stardust components as well as for the whole package.

TODO

• Build bundle size stats for index (entire package)
• Build bundle size stats for /lib
• Build bundle size stats for each component
• Build bundle size stats for each theme
• Ensure size stats are available in each PR for visibility
  • we are going to implement this in a separate PR
• Update release workflow to insert stats for the version number being released

---

Next, we'll make a stats page in the docs for visualizing and advertising this to users. We will extend the stats to include API surface area and render performance later as well.

Implementation details

Computing the statistics

yarn build:stats runs webpack with webpack.config.stats.ts configuration which builds bundles for:

• entire package,
• lib (core),
• all individual components,
• all individual themes.

All build are run in series to avoid memory issues.

Then Unreleased section of docs/src/bundleStats.json file is updated:

{
  "Unreleased": {
    "bundles": [
      ...
      {
        "name": "component-Animation.js",
        "size": 262818
      },
      ...   
    ]
  },
  "0.12.0": {
    /* the same "bundles" structure */
   }
}

Order of all items in the JSON is deterministic so that only change in size (or a new version or package removed/added) results in this file being changed.

Storing the results

New Store bundle statistics step was added to CircleCI config. This script, if run in PR build, checks that the file changed and if so, it commits it back to GIT (see this commit).

Limitations

Every change which results in changed bundleStats.json triggers two build

Store bundle statistics commits a bundleStats.json back to Github if it has changed. This causes several problems in CI workflow:

• As we have Auto-cancel redundant builds enabled in the CircleCI, the build is cancelled,
• as a new commit appears on the branch, it starts a new build.
  • Commiting the stats with [ci skip] does not help as our merge policy says that build for the last commit must be green to allow a merge.
  • If there was a change in the stats (again) the whole loop would happen again - that can happen due to a bug in our stats computation and would always happen for performance stats which have less stable results.

Developers have to deal with mid-air collisions

Every commit on a branch results in a commit from CI - Developers will have to git pull --rebase before pushing, will have to be more careful when force-pushing.

[levithomason]

I split the clean tasks so I could target cleaning just the es build.

[levithomason]

The corresponding clean task for this is called clean:component-info, the util function is called getComponentInfo, I've then renamed the build task for consistency.

The legacy name docgen through me off when trying to use it.

[levithomason]

We loop over each component info file in docs/src/componentInfo. We keep totals of components, subcomponents, and their max, min, and gzip sizes as we loop through them. These are keyed by package.json version number.

[levithomason]

We build stats on every commit, so that component count and size is updated with each change to the src. This is quite slow, so optimizations to the speed are likely warranted.

[levithomason]

We were not formatting js and json files. Now we are.

[codecov]

Codecov Report

❗ No coverage uploaded for pull request base (master@ed50341). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master      #97   +/-   ##
=========================================
  Coverage          ?   88.17%           
=========================================
  Files             ?       42           
  Lines             ?     1455           
  Branches          ?      187           
=========================================
  Hits              ?     1283           
  Misses            ?      167           
  Partials          ?        5

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ed50341...abf4c0c. Read the comment docs.

[levithomason]

Here's the library-level output we're getting.

[levithomason]

Here's the component-level output we're getting.

I chose to key this by displayName for ease of access later. The displayName is our defacto way of storing values everywhere else. Keeping a flat stats file would require us to construct/deconstruct stats file key names to work with stats effectively.

[levithomason]

We were previously including the umd build with ES and CommonJS module types. Now we exclude it.

[miroslavstastny]

I spent some time trying to find a way to commit&push updated stats from CI back to github but haven't found any reasonably solution.

• CircleCI cannot ignore tags,
• even if that would work, each tag would appear as a release in GitHub.

Instead of hacking a suboptimal solution I would rather merge this and progress to the next step which is an external storage. In the mean time we can:

1. either push updates to Git as implemented with all its drawbacks,
2. compute stats on prepush,
3. or store stats as CircleCI artefacts for now.

[layershifter]

I left small comments. My overall opinion: let's ship it.

However, I almost sure that we will need to switch to Rollup in the future, it will give more acurate result and will pass the compilation process much faster.

[layershifter]

Looks quite confusing that we need to have a custom function to compare semver 🤔

[miroslavstastny]

Yes, we can use a package for that, but then we need to handle UNRELEASED_VERSION_STRING explicitly anyway.
Moreover, this will probably be removed once we implement external storage for bundle size.

[kuzhelov]

even given this requirement, it seems that the task would reduce to

• filter out versions with UNRELEASED_VERSION_STRING
  • put them first
• compare rest entries using logic of dedicated package

This approach would be much more preferable to my mind.