[Feature][Vite] Add support for external vite.config.js

[pgfeller]

Command

serve

Description

Angular introduced vite support - which is a great improvement. If I understand the implementation a fallback mechanism to webpack is used in case a feature is not (yet) supported by vite (like e.g. wasm web assembly).

The official documentation recommends to write custom plugins if the default ones to not provide the features required. To get more control over esbuild plugins and to evaluate the possibility to use existing vite plugins I've contacted the people from the angular-builders project and opened a feature request there:
➡️ [Feature Request] - Support to use/add Vite loader plugins

I've created a POC, but realized that I can not inject vite custom configuration without modifying angular-cli builder - or to re-implement it's functions.

It would be desirable if we could derive a custom builder from the vanilla one to add this feature. The respective configuration is currently not available.

The POC also showed that not all vite plugins will work properly with angular - so I understand that this will not be supported by the angular team. But it would be nice if the possibility exists for projects to derive from the code and provide/support custom plugins.

Describe the solution you'd like

It would be desirable that it is easier to derive from the default build / serve implementations to customize them (in this case custom vite config - similar to webpack). This would allow other projects to leverage the existing implementation without hacks and the support of the added or changed functions would be with the respective project (not the core angular team).

Describe alternatives you've considered

At the moment we fall back to webpack - but we've to consider to drop either the wasm packages and replace them with something else; and even switching the framework to vue was considered by the team.

[alan-agius4]

In the Angular CLI, Vite is used as the web server. This means that adding plugins to Vite will only affect the bundles used by the ng serve command and not the bundle created by the ng build command.

Therefore, plugins should be added as part of the Esbuild pipeline, not Vite, so they can be applied to both the dev-server and the application builder. This functionality is already supported by the API.

WASM support for the Esbuild based builders is currently being tracked in #25102

[pgfeller]

Hi @alan-agius4,

thank you for your response!

Therefore, plugins should be added as part of the Esbuild pipeline, not Vite, so they can be applied to both the dev-server and the application builder. This functionality is already supported by the API.

Not sure if I understand you correctly - as esbuild and vite use different plugins to add wasm support. I used the angular-builders to have more control over esbuild and the plugins to perform experiments with the wasm draft standard.

The build step worked - anyhow - I did a prototype to extend the serve executor (ng serve) and it looks like the vite configuration is inline (hardcoded) and not exposed to derived implementations.

Vite itself does not support wasm builds according to the draft standard - that's why I experimented with a fork of the vanilla angular (vite) serve to add vite custom configuration support. It was possible to load vite plugins (merge external config with the hard coded inline config) - but I did see that the angular build, esbuild settings, code or something else are not just "compatible" by adding the plugin. No surprize considering the complexity and evolvement of the different libraries and standards. I understand why a "defined" hard coded plugin list is used for vite and a fallback to webpack in serve will be used if necessary.

However - I did not see that the plugin configuration option for vite is exposed to derived implementations. Yes - there is a plugin mechanism; but in case a project needs a dev-server with customized vite config a fork (full code duplication) of the default server would be required (or a hacky implementation on top of the default implementation). I think a polymorphic approach with a class hierarchy, or other mechanism would be beneficial to the angular ecosystem. Therefore I've opened this issue.

I'm on the road and have not access to the source code of my experiments - but I can provide more details once I'm back next week if that's helpful.

For the moment we'll use webpack in your project; but it would be interesting to know more about the roadmap of angular; as there are rumors that a "own" solution is considered as well instead of vite. I also have some reservations towards esbuild due to the limited number of core maintainers.

I'm not a web expert - and especially not for complex libraries and the history/evolvements (but I do remember how we did branches for IE & netscape ...) - so bare with me if I misunderstood something fundamentally.

with kind regards,
Patrik

[alan-agius4]

@clydin is currently looking into WASM support and we are hopeful that this will be available in the version 18 timeframe.

Regardless of this, if additional plugins need to be added to the build, they should be incorporated into the esbuild pipeline, not Vite, so they can be applied to both the dev-server and the application builder.

Angular CLI uses Vite purely as a web server; the building of the bundles is handled in the Esbuild pipeline.

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}