Skip to content
This repository has been archived by the owner on Jun 9, 2023. It is now read-only.

Stop building the project as a CommonJS library #248

Closed
wants to merge 2 commits into from

Conversation

msanroman
Copy link
Member

Description

To stop building @bufferapp/ui as a CommonJS library and instead just build it with ES Modules in mind. In the end, bundling and browser support will be handled by the different webpack builds in our frontends, and the CommonJS step is preventing us from doing tree shaking based on what we use this library for on each product.

Testing steps

I'd love for you all to test this in your frontends and report back here if there are any bugs or improvements we can make before shipping this. Here are my recommended steps for testing it:

Checking the current production bundle size with your latest @bufferapp/ui

Install webpack bundle analyzer

If you don't have webpack-bundle-analyzer, install it as a dev dependency in your project root:

yarn install -DW webpack-bundle-analyzer

Instead of tweaking our build step so that webpack-bundle-analyzer always yields its results, create a new script in your package.json that runs that analysis for your prod build. Something like:

"analyze:prod": "<your production build command> && webpack-bundle-analyzer --port 8082 build/stats.json"

...and tweak your webpack config so that you include webpack-bundle-analyzer as a plugin on your plugin list

{
  plugins: [
    // other plugins
    new BundleAnalyzerPlugin({
      analyzerMode: 'disabled',
      generateStatsFile: true,
      statsOptions: {
        source: false,
      },
    }),
}

This will generate a stats.json file every time you run webpack, and the analyze:prod command will trigger the client to read those stats.

Run this analysis and check your @bufferapp/ui bundled size

Now, if everything is set up correctly, you should be able to run yarn run analyze:prod (or npm run analyze:prod) and it will open http://127.0.0.1:8082/ with something like this:

CleanShot 2020-10-21 at 12 33 13@2x

In this case, Engage's production bundle has 200KB included (47KB gzipped).

Let's see if we can make it smaller than that!

Reducing bundle size and testing it again

Install this beta version of the UI library: 5.48.2-beta.df91dcb.

Set up your build process for tree shaking

You need to set "sideEffects": false in your package.json (you might need to do it on all your package.json file if you're using yarn workspaces) and usedExports: true in your webpack config under the optimization settings.

Also, it's important you make sure you're not importing Icons with calls such as import * as icons from '@bufferapp/ui/Icon', since that'll prevent webpack from tree shaking the icons you're not using.

Using imports such as import { ChevronUp } from '@bufferapp/ui/Icon' shouldn't cause issues, but it seems like it is still importing it all, this is something that we need to look into whether it's a build issue on our projects or in the library, or both.

Testing it again

Running analyze:prod again after these changes yields these results:

CleanShot 2020-10-21 at 12 43 47@2x

@bufferapp/ui is now just 106KB parsed / 26.06 KB gzipped!

This is a 47% filesize reduction, and 10% overall vendor bundle reduction for Engage!

Action items

Try the following steps in Account / Analyze / Engage / Publish:

  • Measure bundle size before any changes.
  • Implement tree shaking and install this beta version for @bufferapp/ui 5.48.2-beta.df91dcb.
  • Measure bundle size after any changes.
  • Test that staging works still in the same way.

...and report back here how things are looking!

Links

https://github.com/bufferapp/buffer-engage-client/compare/test/reduce-ui-bundle-size?expand=1

Screenshots (if appropriate):

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

  • My code follows the code style and guidelines of this project.
  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.
  • I have updated the CHANGELOG document.
  • I have added tests to cover my changes.
  • I have performed a self-review of my own code
  • I have tested my changes/additions in the latest Chrome, Firefox, and Safari.
  • I have commented my code, particularly in hard-to-understand areas
  • All new and existing tests passed.
  • I have performed the accessibility audit of my UI changes according to the accessibility doc.
  • [Buffer Engineers] Someone from the Design team reviewed and approved my changes
  • [Buffer Engineers] I have notified the BDS team of my changes in the #proj-design-system Slack channel

@msanroman msanroman linked an issue Oct 27, 2020 that may be closed by this pull request
6 tasks
@msanroman msanroman marked this pull request as ready for review October 27, 2020 17:17
Base automatically changed from master to main January 18, 2021 17:17
@federicoweber
Copy link
Contributor

hey @msanroman should we merge this in or close the PR?

@federicoweber
Copy link
Contributor

going to close this for now

@msanroman
Copy link
Member Author

Yes, thanks @federicoweber !

@philippemiguet philippemiguet deleted the task/esm-build branch June 9, 2023 11:41
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Investigate how to stop building @bufferapp/ui with commonjs
3 participants