I will be happy to help. Pretty busy on Thursday, but rest of the week I shall find time to take a look. The more info you can provide into what are your expectations from me, the better.

Are you looking for documentation as to how to "scope" deptrac using bamarni/composer-bin-plugin for those that would encounter conflicts?

Are you looking for documentation as to how to "scope" deptrac using bamarni/composer-bin-plugin for those that would encounter conflicts?

Exactly.

What do you think about dropping the composer.lock and widen the Symfony dependencies? This would help reduce the conflict potential with project dependencies.

What I foresee the impact of dropping composer.lock to be:

• In the CI pipeline, it has to be generated on the fly, instead of being reused
• Therefore, if the on-the-fly generated list of dependencies introduces a bug, it will fail the CI for PR unrelated bug.
• This is good because: We discover an issue from the dependency definition in composer.json
• This is bad because: The PR submitted will fail for reasons unrelated to the content of the PR.
• What would I ideally do: Keep the composer.lock, BUT. In PR CI GitHub actions, use the existing composer.lock to install dependencies. At the same time, create a nightly/weekly build/CI step that will run all the tests from a freshly generated composer.lock file. The effect is the separation of failures. The PR will only fail when the code submitted fails, and the nightly build will fail only if a bug in the dependencies is introduced.

What do I think about widening Symfony dependencies:

• Looking at the proposed composer.json file, I am happy with how it looks right now. I think that having the constraint on a major version is a good way to go about it.
• The only dependency that we could loosen is IMHO jetbrains/phpstorm-stubs. Also, once things stabilize we could make some formatter-related dependencies into suggestions, like phpdocumentor/graphviz.

We could just put this into the README.md for now.

If needed, I can write a blog post going into excruciating step-by-step details, and we can just add a link to that in the note. But I would not block this PR on this.

We could just put this into the README.md for now.

Note

If you experience Composer conflicts while installing Deptrac, we recommend to "scope" the Deptrac installation using the excellent bamarni/composer-bin-plugin. It allows you to install Deptrac and all its dependencies to a separate "scoped" folder where it cannot have any conflicts with currently installed dependencies. Deptrac has been tested and works well with this workflow.
If needed, I can write a blog post going into excruciating step-by-step details, and we can just add a link to that in the note. But I would not block this PR on this.

A blog post would be awesome.

My concern is with the current deptrac dependencies (e.g. symfomy ^6)
a lot of modern project will have to use the bamarni approach.

But this should not be a blocker.

Blog post PR here: #1474