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
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
This will generate a
stats.json
file every time you run webpack, and theanalyze: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
(ornpm run analyze:prod
) and it will openhttp://127.0.0.1:8082/
with something like this: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 yourpackage.json
file if you're using yarn workspaces) andusedExports: true
in your webpack config under theoptimization
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:@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:
5.48.2-beta.df91dcb
....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
Checklist: