<@UFGCACPE0> I am willing to test vite bundler in ...

# opensavvy

[altavir]

@CLOVIS I am willing to test vite bundler in my projects. But I mostly work with libraries, not applications. Is it possible to use it instead of webpack, not together?

[CLOVIS]

Yes. Vite is completely independent of webpack, it creates its own tasks, so you can always choose which one you want to use by its tasks. The only incompatibility is that they expect slightly different things in the main.html, but that's it.

[CLOVIS]

You can learn more about it here: https://opensavvy.gitlab.io/automation/kotlin-vite/api-docs/vite-kotlin/index.html

[CLOVIS]

However, when creating a library, most of the time no bundler is used at all—the contents of the libraries are mostly the outputs of the Kotlin compiler, so I don't think there's much to do there.

[altavir]

I mean, the most time-consuming thing is waiting for tests to setup

[altavir]

webpack sync is still one of the most time consuming stages in the build

[CLOVIS]

Ah. At the moment, the Vite plugin doesn't touch tests, it just does the final app bundling. I don't know if Vite can improve the test experience, but I'd be very interested if it was possible 👀

[altavir]

I will run some build scans to understand the scale of the problem and bring it back. Maybe it could be a good motivation.

[CLOVIS]

I'm a bit worried integration with all the different JS test frameworks is going to be hell to maintain, but if it is that much faster 👀

Also, how I'm going to report test results to Gradle :/

[altavir]

Here it is. Kotlin JS browser test takes twice as match time as both JS and Wasm compilation together. My hypothesis is that significant portion of that is webpack bundle creation.

[altavir]

For KMath it is dwarfed by native compillation times, but for other projects it is a major problem.

[CLOVIS]

This does also include actually starting the headless chromium, right? Maybe that's the slow part

[altavir]

Probably. I am not sure if it is started on each project. But it definitely does not take 30 seconds (the largest test time on a module, and this module does not have a lot of tests).

[CLOVIS]

If you have some time, can you look at the inputs of the test task and see exactly what it is working with? If it already contains the code to start the test framework etc, then it should be easy to run it with Vite. However, if it doesn't, then I'd have to replicate that :/

[altavir]

I have no idea how regular webpack tests work. I will look into that if I have time.

[CLOVIS]

AFAIK, the Kotlin compiler itself generates methods to expose the Kotlin tests to the JS test framework. If I can take the output of the Kotlin compiler as-is and just call Vite to run them, it's easy. What's worrying me is if there is some webpack-specific logic, in which case I'd have to reimplement it, which might be a problem.