One thing we've learned is that most Angular applications don't have the problem Bazel solves.
but you haven't defined what you mean by most Angular applications. I consider most Angular applications to be enterprise applications, regardless of the size of the enterprise, and therefore they will have the problem that Bazel solves.
Most Angular applications will have a dependency of some sort and even if the Angular side of things doesn't change, there will need to be end-to-end testing on the bits that changed. So the incremental guarantees that Bazel provides are important to most enterprise applications.
As for never making Bazel the default build tool in the Angular CLI is fine as long as it is easy to opt-in and learn.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
You've stated:-
but you haven't defined what you mean by
most Angular applications
. I considermost Angular applications
to beenterprise
applications, regardless of the size of the enterprise, and therefore they will have theproblem that Bazel solves
.Most Angular applications will have a dependency of some sort and even if the Angular side of things doesn't change, there will need to be end-to-end testing on the bits that changed. So the incremental guarantees that Bazel provides are important to most enterprise applications.
As for never making Bazel the default build tool in the Angular CLI is fine as long as it is easy to opt-in and learn.