-
Notifications
You must be signed in to change notification settings - Fork 3.1k
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
[HOLD for payment 2024-10-04] [$250] Avoid packaging WDYR and whole LODASH in JS bundle #48978
Comments
Current assignee @mountiny is eligible for the AutoAssignerNewDotQuality assigner, not assigning anyone new. |
Hey I’m Szymon from Callstack - I will take this over from Hur! |
📣 @szymonrybczak! 📣
|
If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results. If a regression has occurred and you are the assigned CM follow the instructions here. If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future. |
Just a Heads Up, Automation failed Deployed 27/9, Paydate 4/10 |
Triggered auto assignment to @garrettmknight ( |
|
Triggered auto assignment to Design team member for new feature review - @dannymcclain ( |
|
$250 to @ishpaul777 No regression testing required, this was performance improvement and we have included automated way to ensure we do not regress |
Feels like I probably don't need to be on this one. Unassigning. |
Payment Summary
BugZero Checklist (@garrettmknight)
|
Job added to Upwork: https://www.upwork.com/jobs/~021843735541723310379 |
Current assignee @ishpaul777 is eligible for the External assigner, not assigning anyone new. |
@ishpaul777 offer's out to you. |
Paid! |
I reviewed #49059 PR associated with this issue. I will need payment summary to request payment. |
@mountiny can you add another payment summary for Sobit? I can't since I'm his approver in ND. |
Sorry for missing that @sobitneupane Given the testing and review of this PR, we should pay $250 to @sobitneupane as well |
@sobitneupane request when you're ready! |
@garrettmknight @mountiny Be sure to fill out the Contact List! |
Payment summary:
|
$250 approved for @sobitneupane |
Problem
In our JS bundle we see that we have unrelated code bundled which is never used. This adds up to the bundle size which eventually leads to the slower loading time for the app. For example,
why-did-you-render
is present in the JS bundle which is a red flag, since it is installed as a dev dependency. The other case is withLodash
not being able to tree-shake the unused functions.Apart from this, there are some libraries which are listed in
dependencies
whereas the right place for them isdevDependencies
. This doesn't change anything but it's a good practice to keep things where they belong. For example,@kie/act-js
,@kie/mock-github
,@types/mime-db
and others.To summarise, we have three action items that we will discuss in the solutions:
why-did-you-render
in the JS bundleLodash
to tree-shake the unused functionsdevDependencies
Solution
Here's the bundle size as of the baseline ~19.18mb
Avoid bundling
why-did-you-render
in the JS bundle:I couldn't figure out the root cause of it. When I comment out the whole
wdyr.ts
, then we don't have it bundled. I thought itmight be due to the
import type {} from 'wdyr
but it's not the case either. For some reasons,useWDYR
flag is not respected.Now, One of the solution we can apply is to ignore
why-did-you-render
if.env
file is either ofprod
orstaging
. Below is how we can do this inwebpack.common
:Diff
This brings our bundle size to ~19.16mb giving us ~20kb reduction
Allow
Lodash
to tree-shake the unused functionsWe have lots of imports like
import {} from 'lodash
orimport _ from 'lodash
. These all doesn't allow web pack to tree shakeLodash
. This brings in a ~110kb increase to the bundle size.See Lodash size
One solution can be to refactor all these imports to named imports like
import isEqual from 'lodash/isEqual'
.Otherwise, a better and simple solution with less changes is to use
lodash-es
and resolvelodash: lodash-es
in from web pack. This avoids the need of a massive refactor. Since esmodules have better tree-shake support with web pack the syntaximport {} from 'lodash
works in terms of tree-shaking. However, we still have to refactor some imports likeimport _ from 'lodash'
to the named ones.Opting for the second solution brings us ~70kb reduction and the final bundle size is ~19.09mb
Irrespective of the gains, we see that the size of
lodash
andlodash-es
is ~110kb. The reason for this is we have the whole imports or de-structured imports inexpensify-common
. Once we change those to named imports, everything falls into the place andlodash-es
now takes ~50kb, which reduces the bundle size to ~19.04mb.See bundle size
Move the development libraries to
devDependencies
This is self explanatory. We just have to move the libraries which are listed in
dependencies
but their right place isdevDependencies
. This doesn't bring any improvement in the bundle size but it's good to place things where they belong.See diff
Bonus
This is something I found out while figuring out different solutions for tree-shaking
Lodash
. There's a plugin calledbabel-plugin-lodash
which only picks the used code fromlodash
but it didn't work. However, while trying it out we have to set:Now, the
lodash-plugin
takes no effect on our bundle BUT this target setting reduces the bundle size to 18.4mb. This happens because we are now not targeting the oldest possible browser. This is also recommended inbabel
docs to specify the target for having reduced bundle size.From my testing, setting to
target: node, 20
doesn't break anything. We can do QA and see if there's something wrong and adjust the node version accordingly.Final bundle size 18.4mb
Issue Owner
Current Issue Owner: @Upwork Automation - Do Not Edit
Issue Owner
Current Issue Owner: @sobitneupaneThe text was updated successfully, but these errors were encountered: