Respect composer require-dev?

[DanielSiepmann]

Hey,

I'm curious why composer require-dev is not respected within https://github.com/maglnet/ComposerRequireChecker/blob/2.1.0/src/ComposerRequireChecker/FileLocator/LocateComposerPackageDirectDependenciesSourceFiles.php#L13.

Our use case:
We develop a package that suggest installing further dependencies via composer suggest configuration. Inside of our code we use parts of this dependency. The dependency is also required via require-dev, in order to have code while developing and running tests.
Right now the class is reported as missing, as require-dev is not respected.

This might be slightly related to #163 where autoload-dev is discussed.

[DanielSiepmann]

Maybe it would make sense to respect requirements that are listed in suggest and require-dev.

[SvenRtbg]

The historic mission of this project was to identify missing production dependencies. If you once required any earlier Zend Framework 2 component standalone, and then tried to use it, you were hit with plenty of "class not found" errors due to the component not declaring it's dependencies correctly. This has since been fixed, and today all (renamed) Laminas components are usable out of the box.

If you look at the discussion in #163 you see that the maintainers are quite hesistant to extend that mission, possibly allowing the checker to be misinterpreted in all these new cases.

Your package is offering something that can be described as "optional dependencies". This project cannot deal with them - at least not without parsing your code more complex in order to find the condition that will either execute something if dependencies are present, or throw an error or execute alternative code if not.

In fact, from what I'd summarize from the discussions I read in the past, I perceived the maintainers have the strong opinion that there cannot be "optional dependencies".

If you want to make use of this tool, you'd probably have to ignore all the reported parts that relate to you accessing "optional" dependencies. However, as soon as the whole require-dev or suggest entries would be added, you can easily depend on something that isn't covered by a conditional check and would break when being used.

[Ocramius]

However, as soon as the whole require-dev or suggest entries would be added, you can easily depend on something that isn't covered by a conditional check and would break when being used.

require-dev and suggest mean absolutely nothing for downstream consumers of your libraries, so they won't be considered by this tool either.

If you want to support additional third-party dependencies, I suggest to instead:

1. Create an adapter that is specific to the third-party component
2. Put it in an independent codebase (whether that requires a new git repository or a subtree split is up to your preference)

While this does indeed increase maintenance burden, it reduces downstream problems, as your users won't get errors due to missing dependencies in misconfiguration scenarios.

Closing, since the rest of the rationale has been exhaustively covered by @SvenRtbg.

[DanielSiepmann]

Thanks to both of you for clarification. Makes absolute sense to me.