feat: replace frontend-build with vite

[bradenmacdonald]

This is a proof of concept that shows how easily @openedx/frontend-build, a custom wrapper around webpack and babel, can be replaced with Vite.

As far as I can tell, Vite supports all the functionality we need from frontend-build, plus has much better TypeScript integration, is much faster, and most of all requires less maintenance.

The various webpack.*.config file in frontend-build have something like 39+187+213 = 439 lines of code (+41 loc for babel.config.js), whereas the equivalent vite.config.ts is only ~48 lines of code - that's 10x less configuration to maintain.

Notes:

• This works "out of the box" with tutor-mfe and frontend-platform; in fact this PR is the only thing necessary to start using Vite for builds. (Though of course things could be improved even further by modifying tutor and frontend-platform accordingly)
• I'm not sure about i18n message builds nor New Relic integration - those may require additional work

Metrics

Notes on these metrics:

• "Host" = M1 Macbook (arm64), "Docker" = Tutor MFE development container on said host
• For dev server times, the time of the second run of the command was measured; the first typically took twice as long while caches were filled.
• Maximum memory usage is the "maximum resident set size" measured with /usr/bin/time -l. The "peak memory footprint" reported by that command was even more favorable but I'm not sure which metric is better to use.
• The dependencies have only increased, not decreased, because frontend-platform still requires frontend-build as a peer dependency, so webpack and all of its dependencies still get installed.
• What's more, frontend-component-header depends on a bunch of legacy stuff that shouldn't be in the build - babel-polyfill, babel-runtime, and core-js. Fixing that will improve these metrics even further I think.

Screenshots

The only difference in the result I could notice is a change to the default avatar because of how Vite currently handles SVG imports. There is probably a way to make it do the same thing that webpack was doing, but if you look at the code here you'll see that this way is actually simpler and more consistent than what was happening before.

frontend-build	Vite

[openedx-webhooks]

Thanks for the pull request, @bradenmacdonald!

What's next?

Please work through the following steps to get your changes ready for engineering review:

🔘 Get product approval

If you haven't already, check this list to see if your contribution needs to go through the product review process.

• If it does, you'll need to submit a product proposal for your contribution, and have it reviewed by the Product Working Group.
  • This process (including the steps you'll need to take) is documented here.
• If it doesn't, simply proceed with the next step.

🔘 Provide context

To help your reviewers and other members of the community understand the purpose and larger context of your changes, feel free to add as much of the following information to the PR description as you can:

• Dependencies

  This PR must be merged before / after / at the same time as ...

• Blockers

  This PR is waiting for OEP-1234 to be accepted.

• Timeline information

  This PR must be merged by XX date because ...

• Partner information

  This is for a course on edx.org.

• Supporting documentation
• Relevant Open edX discussion forum threads

🔘 Get a green build

If one or more checks are failing, continue working on your changes until this is no longer the case and your build turns green.

🔘 Let us know that your PR is ready for review:

Who will review my changes?

This repository is currently maintained by @2U-aperture. Tag them in a comment and let them know that your changes are ready for review.

Where can I find more information?

If you'd like to get more details on all aspects of the review process for open source pull requests (OSPRs), check out the following resources:

• Overview of Review Process for Community Contributions
• Pull Request Status Guide
• Making changes to your pull request

When can I expect my changes to be merged?

Our goal is to get community contributions seen and reviewed as efficiently as possible.

However, the amount of time that it takes to review and merge a PR can vary significantly based on factors such as:

• The size and impact of the changes that it introduces
• The need for product review
• Maintenance status of the parent repository

💡 As a result it may take up to several weeks or months to complete a review and merge your PR.

[bradenmacdonald]

^ Other than this noImplicitAny line, this file is unchanged from the Vite react-ts template.

[bradenmacdonald]

This file is unchanged from the Vite react-ts template.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 68.20%. Comparing base (a255bbe) to head (a8bf2b4).
Report is 54 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1000      +/-   ##
==========================================
+ Coverage   66.78%   68.20%   +1.41%     
==========================================
  Files          51       45       -6     
  Lines         849      824      -25     
  Branches      176      172       -4     
==========================================
- Hits          567      562       -5     
+ Misses        272      253      -19     
+ Partials       10        9       -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[bradenmacdonald]

This file is unchanged from the Vite react-ts template.

[mphilbrick211]

Hi @openedx/2u-aperture! Would someone mind taking a look at this? Thanks!

[bradenmacdonald]

Note this is being discussed at https://discuss.openedx.org/t/experiment-build-an-mfe-with-vite-instead-of-frontend-build-webpack/12702

[arbrandes]

I'm very interested in getting something like this working before (and if) we migrate to Vite, haha. I'll give it a shot and let you know.

[bradenmacdonald]

It works! I use it in course-authoring all the time. It's much easier and faster than running it inside a tutor container.

Run this command on your host (possibly after npm install since it's sometimes different between host and container versions, especially on ARM), and then you can use it just like the tutor containerized version:

APP_ID=course-authoring PUBLIC_PATH=/course-authoring/ MFE_CONFIG_API_URL='http://localhost:8000/api/mfe_config/v1' npm run start -- --host apps.local.overhang.io

And honestly the MFEs should be fixed so these env vars are the defaults, which would simplify this a lot.

[deborahgu]

@bradenmacdonald, this is a proof of concept PR, right? Should it be closed?

[bradenmacdonald]

@deborahgu Yes, that makes sense. It's not intended to be merged for now.

[openedx-webhooks]

@bradenmacdonald Even though your pull request wasn’t merged, please take a moment to answer a two question survey so we can improve your experience in the future.