Roave
Allow providing hints to make the analysis more useful
Hyped of getting a cool changelog, I just tried this tool against doctrine/migrations 2.0. Unfortunately the result is not really useful: https://gist.github.com/Majkl578/2107492b128c35dff8d2007913d4cde8
Since the project namespace was renamed, almost everything is deemed to had been removed, few classes are detected as changed to interface. No method signature changes are reported at all.
It'd be cool to have some chance to provide hints to the tool to help detecting what was actually changed, since git isn't unfortunately useful in this case.
Current behavior
Everything is removed or changed to interface, no signature/type changes reported.
Wanted behavior
Providing hints file with some metadata:
- namespace was changed from X to Y
- class was renamed from X to Y
- method was renamed/moved from X to Y
- etc.
Note that these would still be (correctly) reported as BC breaks, but in a more useful way.
Aye yes this is a really good idea: use context to figure out how to continue. At the moment we simply bail out of the evaluation, but if we know a rename has happened we.shoild be able to work on the assumption the "thing" is really 1-to-1. First step: detection of whole namespace renames (!?)
Renames are tricky, as we can really only "guess" them. Even GIT gets those wrong 90% of the time, unless explicitly specified.
In my opinion, this is a huuuuuuuge rabbit hole that should probably be first extracted into a tool that is capable of tracking changes (in any Tree structure of arbitrary depth) in such a way that renames are easier to follow, and then we can integrate that tool here. If we don't do that, we create a massive amount of work for something without a clear definition of "how to track a rename".
Note: I'm all for the feature, I'm just really worried about creating more work (a lot more, including dozens of people wondering why renames are detected in a flaky way) than what is being described here.
If we work on the assumption only a git rename is detected, and that PSR-0/4 is used (analyse composer) it could potentially work (mostly spitballing so there may be a problem) But I do agree it could be a useful separate tool. Prototype here and split out perhaps once a PR is finalised?
I'd prototype somewhere else at first: this can get extremely messy extremely quickly.
If we figure out a stable and reliable solution, then we can squash it in this repo, but let's try keep things extremely limited, as we know very well that we got limited time to work on anything at all.