Skip to content
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

Merged
merged 9 commits into from
Sep 8, 2022
Merged

Cc/smaller bundle #3725

merged 9 commits into from
Sep 8, 2022

Conversation

ChristopherChudzicki
Copy link
Contributor

@ChristopherChudzicki ChristopherChudzicki commented Sep 6, 2022

Pre-Flight checklist

  • Testing
    • Code is tested
    • Changes have been manually tested
  • Settings
    • New settings have reasonable development defaults, if applicable

What are the relevant tickets?

#3714

What's this PR do?

  1. This PR reduces the bundle size of open discussions and infinite corridor:
                            master      this branch
    ------------------------------------------------                        
    Open Discussions:       7.5M        4.2M
    Infinite Corridor:      5.8M        2.5M
    
  2. Additionally, added webpack-bundle-analyzer to both webpack configs so that we can more easily see what is contributing to our bundle size.

How does this reduce bundle size?

  • Primarily, this reduces the bundle size by removing the factory functions from our local modules's top-level exports. So:
// Before:
import { makeLearningResource} from "ol-search-ui"
// Now:
import { makeLearningResource} from "ol-search-ui/build/factories"

See #3714 for more.

How should this be manually tested?

  1. In the watch container, run NODE_ENV=production yarn run build.
  2. Run ls -lh frontends/infinite-corridor/build and ls -lh frontends/open-discussions/build.
    • Check that the JS bundles are smaller like I said. Check that there is
    • Check that there is no report.html file
  3. In the container again, run WEBPACK_ANALYZE=True NODE_ENV=production yarn run build.
  4. Open 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.

Screen Shot 2022-09-07 at 10 26 30 AM

@codecov-commenter
Copy link

codecov-commenter commented Sep 6, 2022

Codecov Report

Merging #3725 (0ea64d0) into master (735d2dd) will decrease coverage by 0.00%.
The diff coverage is 82.35%.

@@            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     
Impacted Files Coverage Δ
frontends/ol-search-ui/src/components/Facet.tsx 50.00% <ø> (ø)
frontends/ol-search-ui/src/factories.ts 50.98% <40.00%> (-0.95%) ⬇️
...ends/infinite-corridor/src/api/fields/factories.ts 100.00% <100.00%> (ø)
...ontends/infinite-corridor/src/pages/SearchPage.tsx 81.66% <100.00%> (ø)
frontends/ol-forms/src/components/SelectField.tsx 75.00% <100.00%> (ø)
...src/components/ExpandedLearningResourceDisplay.tsx 70.00% <100.00%> (ø)
frontends/ol-search-ui/src/util.tsx 64.94% <100.00%> (-0.71%) ⬇️
frontends/ol-widgets/src/factories.ts 76.31% <100.00%> (+0.64%) ⬆️
search/api.py 95.93% <0.00%> (-1.17%) ⬇️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

@@ -31,7 +31,6 @@
"ol-util": "workspace:*",
"ol-widgets": "workspace:*",
"postcss-loader": "^7.0.1",
"ramda": "^0.28.0",
Copy link
Contributor Author

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"
Copy link
Contributor Author

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

Comment on lines +34 to +35
margin-left: $carouselSpacing*0.5;
margin-right: $carouselSpacing*0.5;
Copy link
Contributor Author

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.
Copy link
Contributor Author

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.

@ChristopherChudzicki ChristopherChudzicki marked this pull request as ready for review September 7, 2022 15:23
@@ -1,5 +1,6 @@
import { faker } from "@faker-js/faker"

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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"

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
import { faker } from "@faker-js/faker"
import { faker } from "@faker-js/faker/locale/en"

Copy link
Contributor Author

@ChristopherChudzicki ChristopherChudzicki Sep 8, 2022

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.

Copy link

@Shinigami92 Shinigami92 Sep 8, 2022

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"

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
import { faker } from "@faker-js/faker"
import { faker } from "@faker-js/faker/locale/en"

@abeglova abeglova self-assigned this Sep 8, 2022
Copy link
Contributor

@abeglova abeglova left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants