RFC: future of this package

[ShGKme]

I'd like to discuss the future of this package since we are migrating to @nextcloud/vite-config.

Current state

• We are actively working on @nextcloud/vite-config, migrating to it, and call the migration a performance improvement for apps
• This config is almost not maintained for a while

Issues with webpack-vue-config

1. 🐌 It is slow and requires much RAM for a production build
2. 📦 It injects CSS into JS impacting web performance
3. ⛓️‍💥 Bad extending. It just exports config which is then mutated, making it not configurable on high level and less stable for changes
4. 🌲 It has an old issue with less effective Tree Shaking

These issues can be solved:

1. Migrating from babel + ts-loader + Terser to ESBuild makes it much faster (requires even less RAM than Vite)
2. Adding MiniCssExtractPlugin to extract CSS
3. Adding a good support for extending and configuration similar to @nextcloud/vite-config
4. Not solvable afaik

Also, there is RSPack, a Rust-based Webpack compatible bundler.

Issue with Vite

1. 🍴 It requires much more RAM on a production build than Webpack + ESBuild
2. 🔬 It has an old problem with multiple JS entry points. It's optimized for building libraries and results in tons of micro-chunks-which is bad for performance. It is not so configurable in chunk generation as Webpack. it is not a problem for typical Vite users with index.html entrypoint, but it is for Nextcloud apps (example - text app).
3. 🔎 Still lack of plugins. For even basic things we create our own plugins or use not widely used ones

Some problems might be solved via rolldown (likely brining new in the beginning) or fixed in the future.

Further options

1. Consider Vite the only recommended option

And mark this package as deprecated and maintenance-only

2. Support both

And develop a new major of nextcloud/webpack-config with some problems solved.

[skjnldsv]

1. Consider Vite the only recommended option

👍

[ShGKme]

2. Support both

👍

[st3iny]

I'd also favor supporting both to not incur the additional cost of migrating apps to Vite, too. Migrating to Vue 3 alone in one, atomic step is enough work already.

Additionally, the missing support for incremental builds (of Vite) makes the developer experience really slow and bad for large apps. (Yes, I'm aware that the vite dev server should be used but it doesn't really work in the Nextcloud ecosystem right now.)

[susnux]

We should focus on Vue3 migration first - so if someone has time and energy also porting this config then it makes sense to save some time.

On the long run I am not so sure, IMHO we should unify on one bundler as maintaining multiple solutions or even custom solutions is wasting a lot of energy. I am not a psychic but while rspack is quite nice it still suffers from the webpack flaws in technology (not speed!) so my guess would be if Rolldown will be ready within this year it will very likely become the de-facto standard in the Vue ecosystem.

(TL;DR; 👍 for keeping this at least until we migrated Nextcloud to Vue3)

---

to not incur the additional cost of migrating apps to Vite, too. Migrating to Vue 3 alone in one, atomic step is enough work already.

Makes sense and agree.

Additionally, the missing support for incremental builds (of Vite) makes the developer experience really slow and bad for large apps. (Yes, I'm aware that the vite dev server should be used but it doesn't really work in the Nextcloud ecosystem right now.)

Partly true.
For large apps like text (>10MB! minified! assets) the build takes some time.
But as you already mentioned using the dev server is the way to go here, and this one is very fast!
I tried it lately when the text teams announced it and its nearly instant and even has hot module reloading.

So I do not understand what "does not work in Nextcloud ecosystem" means, as all that is required is to have a reverse proxy configured (this depends on your general development setup, e.g. for me I have a ~10 line nginx config that maps everything to localhost:8081 and apps/APPTODEVELOP/ to localhost:5173. Nothing else needed - no HMR enabler nothing).

If you want to see what I meant with fast:

Bildschirmaufnahme_20250404_234048.webm

[st3iny]

So I do not understand what "does not work in Nextcloud ecosystem" means, as all that is required is to have a reverse proxy configured (this depends on your general development setup, e.g. for me I have a ~10 line nginx config that maps everything to localhost:8081 and apps/APPTODEVELOP/ to localhost:5173. Nothing else needed - no HMR enabler nothing).

Yeah, that is what I'm talking about. People have to adjust their dev setups (reverse proxies) to make it work. It won't just work by running npm run dev or something similar. (I started a simple PoC that would make it work this way: https://github.com/st3iny/nextcloud-vite-proxy/)