-
Notifications
You must be signed in to change notification settings - Fork 0
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
Reduce bundle size fortawesome #1289
Reduce bundle size fortawesome #1289
Conversation
Important Review skippedAuto reviews are limited to specific labels. 🏷️ Labels to auto review (1)
Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
@@ -1,6 +1,6 @@ | |||
import React from 'react'; | |||
|
|||
import { faCreditCard } from '@fortawesome/pro-regular-svg-icons'; | |||
import { faCreditCard } from '../font_awesome/regular'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using relative imports; Locally I kept getting
[webpack-cli] ModuleNotFoundError: Module not found: Error: Can't resolve 'src/font_awesome/solid' in '/Users/domschab/Work/rails-server/node_modules/@user-interviews/ui-design-system/lib/Accordion'
When building rs shakapacker
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can look at absolute imports without reexporting this as a nice to have in the follow up
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can address the best course of actions for relative imports in a follow up PR; I was reading up about it and this may be tricky to get done. Adding alias in RS shakapacker config doesn't seem like a good solution
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is DS wired up to respect ts
files? I'm assuming it is... but if it only had TSX until now then that could be why its not resolving
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is DS wired up to respect ts files?
I think so; we've had .ts
files here for a while. Based on what I was reading, it might seem like webpack/shaka might also have be aware of the correct alias configuration for bundling/resolving modules (which that seems weird to add an alias in shaka config in rs repo). So it may not be enough to specify an alias in .babelrc
file in DS repo. Happy to look more into this in a separate PR
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is that an error with rails server, or building DS?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
rails server; there's no error building DS
@@ -4,7 +4,7 @@ import { | |||
type ColProps as ReactBootstrapColProps, | |||
} from 'react-bootstrap'; | |||
|
|||
import { useDeprecationWarning } from 'src/utils'; | |||
import { useDeprecationWarning } from '../utils'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This actually failed for me as well locally so using relative (looks like a new addition that wasn't released yet to rs repo)
[webpack-cli] ModuleNotFoundError: Module not found: Error: Can't resolve 'src/utils' in '/Users/domschab/Work/rails-server/node_modules/@user-interviews/ui-design-system/lib/Container'
When building rs shakapacker
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cc @jeffbax
(and this is example from a different PR from a couple of days ago that would make a rs build fail if we tried to merge newest DS to rs)
with relative imports to utils / icons in DS, RS build works. The problem here is defining aliases for internal of DS package that will also work with RS build. That could be looked at when we incorporate rollup as a follow on, but the PR in current states works with rs build.
src/font_awesome/regular.ts
Outdated
|
||
/* eslint-disable no-restricted-imports */ | ||
|
||
import { library } from '@fortawesome/fontawesome-svg-core'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So the old app did this originally because we were still using <i class='fa fa-fooo' />
elements and this would make things available outside of webpack context for us... I would expect tree shaking to take care of not importing things that were not used (if may be a bit slow)
Are we totally sure the prod bundle is affected here? 5.4mb is certainly massive savings so I don't want to undermine what could be a huge win... I just want to make sure the bad things we think are happening are happening.
The thing I would generally like to see if possible, is for the DS to provide FA to the rails app so they are always in sync and managed in one spot.
I don't know if this might be digging us deeper on a mechanism we don't want to rely on.... but maybe that is not the case.
I guess my other concern in the rails app was that these "libraries" didn't tend to get things removed when they were not used any longer. Which is why tree shaking is useful, it should get what people don't clean up.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All that said, being deliberate also might mean a faster build for us to not depend on tree shaking. I'm mostly just saying I'm not totally familiar with what has changed for FA in the past few years.
❓ Do we know tree-shaking is in fact turned on for DS?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tree shaking is turned on for shakapacker when in production mode by default, but we're serving our DS components as a package that are transpiled with babel into commonJS and webpacker/shakapacker does not support tree shaking for commonJS modules https://webpack.js.org/guides/tree-shaking/#conclusion
Ensure no compilers transform your ES2015 module syntax into CommonJS modules (this is the default behavior of the popular Babel preset @babel/preset-env - see the documentation for more details).
It's very likely that we're having unnecessary ~5MB of fortawesome in prod based on few tests I run
Shakapcker locally with prod setting with current DS from main
Shakapacker locally with prod setting and DS from this branch. 4.9MB less
Bundles locally with prod setting and DS from this branch
Bundles locally with prod setting with current DS from main
You can see we're importing all of @fortawesome
icons and that matches with screenshot from prod I added in PR description.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Font awesome also mentions this in their docs
https://docs.fontawesome.com/apis/javascript/tree-shaking
Known Issues with Tree-shaking
Production Mode
Webpack only performs tree-shaking when the --mode=production flag is used. This enables the UglifyJsPlugin which performs the optimization. To nerd out for a second; this plugin is actually doing “dead code elimination” which is a slower process than the canonical tree-shaking but the results are similar.
Rollup enables tree-shaking by default but it does so only with ES modules. Font Awesome provides ES modules in all of its NPM packages so you should be good-to-go.
Which seems to confirm that currently we're not getting benefits of tree shaking or 'dead code elimination' for @fortawesome
and that aligns with screenshots above comparing bundle sizes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think my question is whether we are building the DS "in production" -- if we build it in production with tree shaking, then when it gets to the rails server it would presumably already have removed the unused icons?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think my question is whether we are building the DS "in production" -- if we build it in production with tree shaking, then when it gets to the rails server it would presumably already have removed the unused icons?
It doesn't seem like that's what happens today per screenshots above (you can see icons taking much more space than needed in screenshots above).
When you transpile your code into commonJS (what we're doing today with DS components) then treeshaking for that portion of the code is not working per
webpacker/shakapacker does not support tree shaking for commonJS modules https://webpack.js.org/guides/tree-shaking/#conclusion
Ensure no compilers transform your ES2015 module syntax into CommonJS modules (this is the default behavior of the popular Babel preset @babel/preset-env - see the documentation for more details).
@@ -1,6 +1,6 @@ | |||
import React from 'react'; | |||
|
|||
import { faCreditCard } from '@fortawesome/pro-regular-svg-icons'; | |||
import { faCreditCard } from '../font_awesome/regular'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is DS wired up to respect ts
files? I'm assuming it is... but if it only had TSX until now then that could be why its not resolving
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lets take the short term win here if its working, but lets try to check out Rollup in the DS working group as I do think ideally we don't have to do this type of thing and its hopefully a straightforward change to package.json
I looked at our bundle sizes and I've noticed that our fortawesome is occupying 2 top spots for dependencies
From prod
We're already guarding against it the rs repo, but looks like we never did that for DS
Locally before changes
Locally after changes
Shedding off about 5.4 MB