feat: integrate composer-dependency-analyser for dependency analysis

[mairo744]

Q	A
Documentation	no
Bugfix	no
BC Break	no
New Feature	no
RFC	no
QA	yes

Description

This PR introduces shipmonk/composer-dependency-analyser to improve dependency management.

• To detect dead/misplaced/shadow dependencies
• To enforce stricter dependency hygiene in CI, preventing similar issues in the future.

[Xerkus]

I am going to decline this PR. This QA tool was not approved by TSC vote.

The one approved was maglnet/composer-require-checker. It is run in our CI container via matrix action job.

[mairo744]

Thanks for your time and feedback.
I wasn’t able to find a documented TSC vote or official record explicitly approving maglnet/composer-require-checker over other tools. Are the results of such votes public? Is there a place where approved tools for Laminas are listed?

Would it be possible for me to propose shipmonk/composer-dependency-analyser for a TSC vote? It can also detect dead and misplaced dependencies, which could add extra value.

[Xerkus]

Hm. I was pretty confident we had QA tools on our agenda but minutes have no mention of it. We might have resorted to a discussion without a topic on the agenda or vote.

composer-require-checker was introduced here but we did not adopt it widely since it causes quite a bit of grief with dependencies.
laminas/laminas-ci-matrix-action#50

Consistency with the tooling usage is very important because it is guaranteed we will have issues and having to deal with different sets of issues in different repositories strains the limited maintenance capacity. For example some repos use prophecy and some others use mockery and it noticeably hampers the ability to upgrade dependencies there right now as the push for php 8.5 happens.

Proper flow for QA tooling is to prepare example for the tool setup and usage. Propose it at a TSC meeting. After discussion once we got the TSC decision it needs to be consistently rolled out across both organizations.

You would need to put this on the agenda for the next TSC meeting https://github.com/laminas/technical-steering-committee/blob/main/meetings/agenda.md

We should postpone this and also consider adopting a separate install method for tools that does not put them in require or require-dev.
@gsteel tried out alternate setup in the component he maintains and it seems to be working so far.

[mairo744]

Thanks for the clarification and additional context. I understand the process now.
I think this PR can be closed for now and we can revisit the idea later with a proper proposal — or alternatively, just detecting only shadow dependencies via maglnet/composer-require-checker