-
Notifications
You must be signed in to change notification settings - Fork 2
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
Cc/smaller bundle #3725
Cc/smaller bundle #3725
Conversation
Codecov Report
@@ Coverage Diff @@
## master #3725 +/- ##
==========================================
- Coverage 86.89% 86.88% -0.01%
==========================================
Files 329 329
Lines 13991 13988 -3
Branches 2301 2300 -1
==========================================
- Hits 12157 12153 -4
Misses 1561 1561
- Partials 273 274 +1
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
a274e9e
to
0ea64d0
Compare
@@ -31,7 +31,6 @@ | |||
"ol-util": "workspace:*", | |||
"ol-widgets": "workspace:*", | |||
"postcss-loader": "^7.0.1", | |||
"ramda": "^0.28.0", |
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 also removed all usage of ramda in this PR because:
- it was easy to remove. All of our usages have simple native JS alternatives or analogous lodash functions
- we were including it twice in our bundle accidentally.
If we need it for something, we can definitely add it back.
import * as R from "ramda" | ||
import { makePaginatedFactory, Factory } from "ol-util" | ||
import { LearningResourceType, factories } from "ol-search-ui" | ||
import { makePaginatedFactory, Factory } from "ol-util/build/factories" |
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 would very much have preferred an import from ol-util/factories
instead of ol-util/build/factories
. It's fairly easy to configure that with Node subpath exports.
But as far as I can tell, making that work with Typescript means moving to ESM-style module resolution, which is a fairly big change. So I went for the uglier ol-util/build/factories
imports. From microsoft/TypeScript#33079 (comment) (emphasis mine):
TypeScript doesn’t yet have a resolution mode suitable for most bundlers, and package.json exports are not yet configurable independently of the module resolution mode on the whole. This is discussed at length in microsoft/TypeScript#50152.
Related: https://www.typescriptlang.org/docs/handbook/esm-node.html
margin-left: $carouselSpacing*0.5; | ||
margin-right: $carouselSpacing*0.5; |
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 is from running npx sass-migrator division **/*.scss
, which fixed some deprecated Sass syntax.
(At one point on this branch I had a failing build that I thought might be related to a sass issue, so I was trying to clean up some warnings.)
}) | ||
|
||
it("Returns true for numbers", () => { | ||
// _.isEmpty(5) returns true; this is different from ramda. |
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.
If the different ever matters to us, I would be surprised.
@@ -1,5 +1,6 @@ | |||
import { faker } from "@faker-js/faker" |
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.
import { faker } from "@faker-js/faker" | |
import { faker } from "@faker-js/faker/locale/en" |
As you are not changing the locale at runtime, just use the en
locale
@@ -1,7 +1,8 @@ | |||
import { faker } from "@faker-js/faker" |
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.
import { faker } from "@faker-js/faker" | |
import { faker } from "@faker-js/faker/locale/en" |
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.
Aside for other mitodl folks: Shinigami92 is one of the faker-js maintainers and previously noted that using specific imports like this would reduce faker's footprint.
Personally, I'm somewhat inclined to keep the faker imports as is because:
- faker should not influence the overall bundle size at all. The fact that faker was influencing our bundle size prior to this PR was a mistake.
- the subpath import is a little more verbose. I'm not really confident that we'd use it consistently, and per ☝️ I do not understand the benefit.
Shinigami92: If I've misunderstood and there is some benefit I'm not seeing, feel free to let me know.
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.
No you are right 👍
I would suggest to upgrade to v8 as soon as it's available
This would only be a benefit until we have managed better locale handling on our side.
@@ -1,9 +1,8 @@ | |||
//@ts-expect-error casual-browserify does not have typescript types | |||
import casual from "casual-browserify" | |||
import { faker } from "@faker-js/faker" |
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.
import { faker } from "@faker-js/faker" | |
import { faker } from "@faker-js/faker/locale/en" |
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.
LGTM
Pre-Flight checklist
What are the relevant tickets?
#3714
What's this PR do?
How does this reduce bundle size?
See #3714 for more.
How should this be manually tested?
watch
container, runNODE_ENV=production yarn run build
.ls -lh frontends/infinite-corridor/build
andls -lh frontends/open-discussions/build
.WEBPACK_ANALYZE=True NODE_ENV=production yarn run build
.frontends/infinite-corridor/build/report.html
in your browser to see the bundle analysis.Screenshots
This is the infinite corridor bundle report... There's still some work we could do, e.g., CKEditor is only used by moderators, I think it could be loaded dynamically. But that can be looked into separately.