You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now, the formatter configuration is using as section keys the actual names of the formatters (graphviz, codeclimate). If we change the keys to something more generic (for example graphviz => graph), it would make it reasonable to reuse the same configuration for multiple formatters like #948 or other automation/CI formatters.
That way we also get around the pesky problem of merging those parameters from multiple config files.
The text was updated successfully, but these errors were encountered:
I have an alternative solution in mind. I want the config to be very specific, instead of having a generic one.
Right now we pass the whole config to each formatter, because I initially wanted to move away from semantic config. Now that we know, it's not easily possible (without breaking merging multiple files) we can make this more specific again.
In the future, I think each formatter should have its dedicated configuration (if the formatter needs it) and extensions can add their own config using PrependExtensionInterface. We would need to make adjustments to register an extension in Deptrac for that, but the foundation is there. If this is too complex, which I can understand, then we can still configure the formatter via service configuration in the deptrac.yaml, i.e. provide the configuration directly to the service instead of via configuration. The downside is, that configuration likely needs to be scalar for this to work easily, but that is the status quo anyways.
Well you are the go to Symfony guy for me for development of this repo. So I would defer to your judgement as to what is reasonably simple to implement.
Right now, the formatter configuration is using as section keys the actual names of the formatters (
graphviz
,codeclimate
). If we change the keys to something more generic (for examplegraphviz
=>graph
), it would make it reasonable to reuse the same configuration for multiple formatters like #948 or other automation/CI formatters.That way we also get around the pesky problem of merging those parameters from multiple config files.
The text was updated successfully, but these errors were encountered: