Plugins added to the buildApplication() API do not affect prebundling

[HazzMan2409]

Command

serve

Description

Looking at the buildApplication() API https://github.com/angular/angular-cli/blob/main/packages/angular/build/src/builders/application/index.ts#L150 you can add plugins to the build (via the extensions parameter). However, these plugins do not affect Vite's prebundling https://github.com/angular/angular-cli/blob/main/packages/angular/build/src/tools/vite/utils.ts#L101C7-L101C14.

This feature request is to ensure these plugins do affect prebundling.

This will mean that non-standard things that exist in third-party code can be configured to enable prebundling. I know we can exclude the third-party code from prebundling but that causes a dev server performance hit and some libraries have hundreds of entry points (which is a pain because the exclusions don't support wildcards).

Describe the solution you'd like

No response

Describe alternatives you've considered

No response

[alan-agius4]

I'm curious about the use case for running plugins on libraries. Since plugins execute sequentially, adding them to the Vite pipeline could produce different results compared to the final build. Additionally, while Vite currently uses esbuild for prebundling, this may change in the future, potentially making such implementations and dependencies fragile.

As to supporting wildcards support for prebundling excludes this is being tracked in #29170

[HazzMan2409]

Unfortunately, I am dealing with a library that has non-standard import statements. The library assumes the imports are processed in a way that the current loaders API does not support.

It felt appropriate to add the plugins I am using to deal with the non-standard imports into the prebundling.

I suppose I could patch the library but it would be a pain because of the hundreds of entry-points and I’d need to use a bundler to catch all of the import statements properly.

[HazzMan2409]

I understand that this is not a strong use case btw :)

[alan-agius4]

Can you provide an example of what you mean by non standard imports?

[HazzMan2409]

Ofc, the library code has things like:

import properties from './example.properties';

console.log(properties.hello.example);

Where ./example.properties looks like:

hello.example=world

[alan-agius4]

I would recommend filing an issue with the library, as it generally reflects poor practice for a library to rely on configuring the bundler for proper functionality. Libraries should ideally be designed to work independently of specific bundler configurations to ensure greater flexibility and ease of integration across different environments.

[HazzMan2409]

Agreed, thanks for the info. I'll close this off.

[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.}