[Build] Investigate using Vite for building Open MCT

[unlikelyzero]

Is your feature request related to a problem? Please describe. Vite is a next generation node tooling environment which is designed to increase the speed of development by enforcing some opinionated standards. Generally these are all positive improvements so we should consider the migration.

This ticket captures the work necessary to investigate and migrate to Vite with Open MCT.

Describe the solution you'd like

• [ ] Proof of concept of rewriting our build tooling to work with Vite
• [ ] Documentation and gap analysis of what cannot be immediately converted
• [ ] Plan for migration.

Describe alternatives you've considered We've considered keeping webpack as our buildtool.

Additional context Vite did not existing until recently and since Open MCT is a mature and long-running project, there was no specific reason it was ignored until now

[shaynababe]

Vite is very nice if the code is ready MCT is not ready

Vite uses rollup and a TS library could be build, This was my last attempt to use rollup, The MCT code is okay , it needs to update to work with a TS transplier in rollup , if you wish to stay with ES code make it uniform the VUE and HTML code can be used if update, The new babel and eslint will be a help doing the code cleanup

[LeoDog896]

I would be interested in picking this up after https://github.com/nasa/openmct/issues/6591 is merged.

[ozyx]

@LeoDog896 Would be very interested to see the differences between webpack / vite wrt build time, bundle size, performance, etc. Feel free to get started and let us know if we can help in any way.

[LeoDog896]

I did some investigating into this:

• Using Vite means we need to use Jest or, preferably, Vitest, instead of the (now deprecated) karma
  • Vitest is faster than Jest on ESM repositories, and Jest is 2-3x faster because it uses JSDom to speed up its tests.
  • (References to blogs are probably not the most credible sources)
• Vite loves ESM. It can build a UMD module, but most likely, the entire repository needs to be converted to a module first (however, good news! This generally has a good history of reducing bundle sizes)
  • Thus, backwards compatibility can be preserved.

It may be a good idea first to switch the repository to ESM under webpack, then introduce a secondary PR to move to Vite. Otherwise, the Vite PR would introduce both a tooling and module change.

[unlikelyzero]

Using Vite means we need to either use Jest or, preferably, Vitest, instead of the (now deprecated) karma

@LeoDog896 part of the reason we invested so heavily into playwright was to detangle ourselves from karma. I mistakenly assumed karma would already be dead like it's companion project Protractor.

Given how much of the community has moved to jest, it would be a hard sell to invest in vitest at this point. We may very well find ourselves right back in this exact scenario in 3 years. Maybe ChatGPT 6.5 will have a codemod ready 😄

As far as I can tell, the only benefit for a project like ours to migrate to vitest instead of Jest would be that we'd reduce the number of config files to support HMR? Something we have actively controlled for a few years in our testing.

Could you identify the benefits for vitest over jest? The problem with Jest has always been that the JSDOM is not a "real" browser in my mind. Something which plagued phantomjs.

[LeoDog896]

Using Vite means we need to either use Jest or, preferably, Vitest, instead of the (now deprecated) karma

@LeoDog896 part of the reason we invested so heavily into playwright was to detangle ourselves from karma. I mistakenly assumed karma would already be dead like it's companion project Protractor.

Given how much of the community has moved to jest, it would be a hard sell to invest in vitest at this point. We may very well find ourselves right back in this exact scenario in 3 years. Maybe ChatGPT 6.5 will have a codemod just for this scenario 😄

As far as I can tell, the only benefit for a project like ours to migrate to vitest instead of Jest would be that we'd reduce the number of config files to support HMR? Something we have actively controlled for a few years in our testing.

Could you identify the benefits for vitest over jest? The problem with Jest has always been that the JSDOM is not a "real" browser in my mind. Something which plagued phantomjs.

The only benefit is that it integrates well with Vite (assuming we use it), and because it's ESM first, it has marginal performance benefits. However, I see your concerns about Vitest's popularity, and a plugin to integrate Vite with Jest should work well.

[LeoDog896]

Though, Vitest does have a browser mode, but that probably shouldn't be the reason why it's used as that feature is also unstable.