Allow filtering out dependencies introduced by deprecated methods and classes.

[Daniel Kinzler]

When refactoring a code base that needs to maintain a stable interface, it's often necessary to keep undesirable dependencies in deprecated methods until some later release. It would be useful to be able to see what the dependencies would look like with all the deprecated stuff removed. The respective filter would skip all classes and methods with the @deprecated tag in the documentation.

[Michael Haeuslmann]

Never had a use for that come up myself, because I would consider it a red test, but on the other hand I'm aware that when it comes to proper legacy those tests stay red for a loooong time 😉

This should be easy to implement however so I'm just going to add it too the next version.

Oh and I would probably just exclude all deprecated sources. I scan more than just the signatures so a property type hint which is deprecated should also be ignored.

[Daniel Kinzler]

Yes, ignoring all deprecated sources was the idea.

I'm looking into this for use in the MediaWiki platform evolution program, which aims to untangle the code that is running Wikipedia. It has been growing for 15 years, has a large install base and literally thousands of extensions, so yes... tests say red a long time, because making a breaking change takes a year or so. Seeing progress in the meantime would be really nice.

[Michael Haeuslmann]

• mark in text output

[Michael Haeuslmann]

@brightbyte how would you deal with this

class A {
    /** @deprecated */
    private B $b;

    public foo() {
        B::call();
    }
}

So as long as there is one non-deprecated dependency, the edge will not be marked as deprecated, right? everything else would be really misleading.

[Daniel Kinzler]

So as long as there is one non-deprecated dependency, the edge will not be marked as deprecated, right? everything else would be really misleading.

Yes, absolutely.

Also, consider:

class A {
    /** @deprecated */
    private B $b;

    public foo() {
        $this->b->call();
    }
}

This would be a non-deprecated use of B. The fact that the member is deprecated wouldn't matter. Only if the code doing the call was also deprecated, then it should be ignored.

[Daniel Kinzler]

Are you still working on this? I'm still very interested in this feature...

[Michael Haeuslmann]

I'm being very pragmatic these days, because with my other projects I don't have that much time to spend on dePHPend. This is something that can be done already using:

-e, --exclude-regex=EXCLUDE-REGEX        Exclude all dependencies which match the (PREG) regular expression.

This issue is 2 years old (mea culpa 🙈) but this can be done by grepping for things that have @deprecated attached to them, concatenating them and then passing them as filters to that option. This is of course not perfect, but when used for migration or big architecture refactoring, this could even become part of a test.