-
Notifications
You must be signed in to change notification settings - Fork 12k
Circular dependency checker can be slow #19794
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
Comments
Thanks for identifying the slow plugin, it's really helpful to have a specific piece of a build to discuss rather than just a general "build is slow". We had a brief discussion about this in our regular tooling triage meeting. Just for reference, we do have a debug flag for enabling profiling of the Webpack plugins used in a build (doesn't support Webpack 5). This is an internal debug flag, so not a strict public API, but users are welcome to try it, and if it works it might give a little more insight into why a build might be slow: NG_BUILD_PROFILING=true ng serve In general, we don't want to remove the circular dependency check solely for performance reasons. Although circular dependencies are allowed by browsers and Node, there are a lot of downsides which aren't totally obvious or an issue until a project hits a certain scale. This includes slower incremental builds, coupled compilation between all files in the cycle, and increased difficulty in extracting a library from a cycle. Bazel, Closure compiler, and google3 in general do not allow circular dependencies at all for these reasons. If your build is only 3s normally, but spends an additional 5s checking circular dependencies, that sounds like a performance issue with As another option, you can drop the Webpack plugin and use an ESLint plugin instead. That would run the circular dependency check asynchronously, although it does say it can be expensive and possibly slow down linting. Considering there is a |
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
🚀 Feature request
Command (mark with an
x
)Description
For us the majority of an incremental rebuild time is spent in circular dependency checking
On a largeish hybrid app with complicate imports (in particular, the angularjs part doesn't use modules / barrel files, so the import graph is pretty complicated) a no-change incremental build is about 8s with and 3s without circular dependency checking on a state of the art desktop. There is also no easy way to see how much time is spent in the circular dependency plugin, so took a while to figure that out.
Describe the solution you'd like
Ideally the circular dependency check would run asynchronously, like the type checker.
Describe alternatives you've considered
For now, we have a separate build configuration with
"showCircularDependencies": false
The text was updated successfully, but these errors were encountered: