You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have found internally that the springboot rule is a good enforcement chokepoint for catching errors in the dependency graph. the dupe class checker gets a lot of mileage and has caught a number of mistakes for us.
Another check we would like to have is fail if the count of deps exceeds a certain threshold (configurable in the workspace as per #78). The reason is we have seen cases where the service owner did not realize they were bringing in a massive graph of dependencies.
A specific case was when a service owner added a dependency on a certain SDK (a single dependency) not realizing that the SDK transitively brought in over 125 other SDK dependencies to support many APIs not needed by the service. They could have instead just brought in single, focused, SDK dependency instead.
We will need to pick a default value, which is overridable by attribute. We will decide on that value empirically using our internal collection of services, which provide a good sample.
springboot(
...
check_deps_maxcount=150,
)
The text was updated successfully, but these errors were encountered:
We have found internally that the springboot rule is a good enforcement chokepoint for catching errors in the dependency graph. the dupe class checker gets a lot of mileage and has caught a number of mistakes for us.
Another check we would like to have is fail if the count of deps exceeds a certain threshold (configurable in the workspace as per #78). The reason is we have seen cases where the service owner did not realize they were bringing in a massive graph of dependencies.
A specific case was when a service owner added a dependency on a certain SDK (a single dependency) not realizing that the SDK transitively brought in over 125 other SDK dependencies to support many APIs not needed by the service. They could have instead just brought in single, focused, SDK dependency instead.
We will need to pick a default value, which is overridable by attribute. We will decide on that value empirically using our internal collection of services, which provide a good sample.
The text was updated successfully, but these errors were encountered: