Attempt to improve developer experience with vite

[carlobeltrame]

One big grudge I have with vite is this:

[vite] ✨ new dependencies optimized: core-js/modules/es.function.name.js, core-js/modules/es.array.concat.js

Vite routinely finds new dependencies while I click around the application, and then takes ages to optimize these and reload the page, throwing me back to the last page I was before my click.

This is especially infuriating when developing camp print features:

1. The vite dev server claims it's "ready" after a blazingly short time (e.g. 500ms), then takes about a minute before the login page is populated.
2. I log in. This usually doesn't take too long.
3. I click on a camp, and vite finds the "new" dependencies core-js/modules/es.symbol.js, core-js/modules/es.symbol.description.js, re-optimizes and reloads the page. I'm back at the camp list.
4. I click on the camp again, this time it loads.
5. I click on "Print", and vite finds the "new" dependencies core-js/modules/es.array.splice.js, @sentry/browser, raf/polyfill, re-optimizes and reloads the page. I'm back at the camp dashboard.
6. I click on "Print" again, this time it loads.

That's a lot of additional user interaction with a lot of forced pauses in between. For debugging react-pdf worker problems, I have to do all that on every (!) code change, because I have to delete the node_modules/.vite directory and restart the frontend to make sure the changes go through.

This commit forces vite to optimize the "newly discovered" dependencies during startup, even when it doesn't foresee yet that it will need them later. This effectively fixes steps 3 and 5 from above.

For step 1, I tried to instruct vite to use wget as a "browser" to open the login page as soon as it claims that it is ready. But it only seemed to help some of the time... Maybe we should use Cypress or puppeteer for this instead. My WIP is on this branch if anyone wants to have a look.

[BacLuc]

I also have this problem a lot. Isn't there a possibility to tell vite to preload (and pre optimize) certain modules that will be hit often?

One hacky idea would be to import components in the entrypoint (like index.js or so), which are unused, but get loaded and optimized at startup.

[carlobeltrame]

Yes, optimizeDeps.include is exactly that as far as I can tell. But not sure whether that runs on startup or during the first request though. We could also try to include some vue components in there, but try with my current changes, in my experiments it already helped a lot.