-
Notifications
You must be signed in to change notification settings - Fork 133
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
Irrelevant transient dependencies reported #1218
Comments
This is absolutely a feature. Looks what happens when you "squash" B into the final shape the class will have at runtime: class B {
final public function getVO(): VO { return new VO($this->generate()); }
protected function generate(): string { return "from B"; }
} You absolutely depend on
Obviously, it would not, it would complain about non-existent Deptrac should provide you with a relatively nice message about this being a dependency coming from |
Thinking about it a bit more. Is the argument there that since That would be an interesting case. If that would be the case what would happen if I had: class C {
public function foo(): void {
$var = new B(); //This is clear dependency on B
$vo = $var->getVO(); //Is this dependency on B or on A?
var_dump($vo); //This could be a dependency on VO, but it is not yet implemented in deptrac
}
} It creates another conundrum. I am not opposed to this, just wondering what were your expectations. It is important that |
Hah, interesting indeed. I love the "if you delete it, will it compile" heuristic, since it’s super easy to grasp. That being said, the final case is not atypical in a ports-and-adapters kinda situation. |
I will close this for now due to inactivity and lack of a clear ask in this issue. Feel free to re-open if you need. |
Now assume each class lives in its own layer called like the class wit this ruleset:
deptrac will complain that
B
depends onVO
even though I would say it does not. Bug or feature?The text was updated successfully, but these errors were encountered: