Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

externalPackagesPlugin slows down ng serve substantially #27116

Open
1 task done
sod opened this issue Feb 16, 2024 · 1 comment
Open
1 task done

externalPackagesPlugin slows down ng serve substantially #27116

sod opened this issue Feb 16, 2024 · 1 comment

Comments

@sod
Copy link

sod commented Feb 16, 2024

Command

serve

Is this a regression?

The previous version in which this bug was not present was

Before #26923 existed, which was part of 17.1.1, so I guess angular 17.1.0

Description

angular 17.2.0
vite/esbuild powered application builder

Using the loader option in angular.json like:

"loader": { ".webp": "file", ".svg": "text" },

to support images as ecmascript imports or svgs as inline. This causes angular-cli to add the externalPackagesPlugin which is a giant hit on build performance. For our apps:

angular version watch rebuild time
angular 17.1.0 { "loader": { ".webp": "file" } } 0.8 seconds
angular 17.1.1 { "loader": { ".webp": "file" } } 6.0 seconds
angular 17.2.0 { "loader": { ".webp": "file" } } 6.0 seconds

Those additional 5.2 seconds are also added to the initial build.

My rough idea of the issue is, that the externalPackagesPlugin looks at every single import that doesn't start with . or / and doesn't cache the results. So tons of @angular/..., rxjs, @ngrx/... and similar imports are resolved over and over again. Even if this function only needs 2ms to run, this quickly adds up.

Minimal Reproduction

https://github.com/sod/ng-serve-external-deps-slowdown
image

The only difference between the development and development-slow configurations in the angular.json are:

            "development": {
            },
            "development-slow": {
              "loader": {
                ".webp": "file"
              }
            },

Your Environment

@angular-devkit/architect       0.1702.0
@angular-devkit/build-angular   17.2.0
@angular-devkit/core            17.2.0
@angular-devkit/schematics      17.2.0
@angular/cli                    17.2.0
@schematics/angular             17.2.0
rxjs                            7.8.1
typescript                      5.3.3
zone.js                         0.14.4
@sod
Copy link
Author

sod commented Feb 16, 2024

As as side note. If you intend to just make the externalPackagesPlugin faster but keep the /^[^./]/ regex, this still would be a regression compared to angular 17.1.0.

E.g. if all that the externalPackagesPlugin did was return null, like:

            build.onResolve({ filter: /^[^./]/ }, async (args) => {
                return null;
            });

Then the watcher in our project would still need 1.4 seconds (instead of the 0.8 seconds in 17.1.0 without this plugin).

I guess having esbuild calling a javascript method on nearly every import doesn't come for free. For us it executes this function 7458 times on every change.

I'd prefer if we could stick to buildOptions.packages = 'external'; without the plugin, as that seemed to work fine. Maybe the options.loaderExtension doesn't need to be part of the bail:
CleanShot 2024-02-16 at 15 28 38@2x

After all, loaderExtension are all build-in esbuild loaders. esbuild doesn't support custom loaders like webpack does. Custom stuff must all be implemented as plugins in esbuild.

sod added a commit to sod/angular-cli that referenced this issue Feb 16, 2024
…using custom loader

loaders in esbuild aren't really custom code. You can only choose from the loaders that esbuild provides. So I doubt they require this `externalPackagesPlugin` which comes at a pretty steep cost of 1 second per 1500 imports your project has on every build and watch rebuild.

fixes angular#27116
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants