Print only file path when reporting a correction #5596
Conversation
Generated by 🚫 Danger |
SimplyDanny
force-pushed
the
correction-positions
branch
from
b532c2a
to
a9b9c20
Compare
Omit exact line and column information. Keep the internal logic available for a while in case people complain for good reasons. Then the change can be reverted easily. Reasons behind this change: * What is the position of a correction actually? The position where the rule triggered? The position of the transformed node? * If there's more than a single fix, it's highly likely that all positions (except for the first) are wrong no matter what the answer to the first question is. * Getting the positions right in a rewriter is hard. And there is always the feeling that something is wrong with them - probably because it is. * Even if you get the positions right in a single rule: One run collects positions for all rules that apply to a file and so rewrites in other rules might draw existing positions wrong. * We already have checks for more than one correction position disabled in tests due to these issues.
SimplyDanny
force-pushed
the
correction-positions
branch
from
a9b9c20
to
e807ea6
Compare
|
I think if the information we're providing now is misleading, then suppressing it is ok. The list of problems above makes me think that maybe we're doing something wrong here - they all sound fixable - at the end of the day it's just a set of transformations on a set of files. My personal use-case for autocorrect is that we run it during every build for whitespace correction, colon spacing etc, so no-one ever looks at the actual violation positions, and we never enable autocorrect for new rules - we just fix them manually, or add them to our baseline - not for any principled reason - we just never have. I guess the other use case is having a legacy code-base and doing a huge cleanup sweep - in theory that should work, but personally I'd be a little bit wary of turning on fix for everything and letting rip. If I did care about fix violation positions, and wanted to see them in Xcode for example, I think we could come up with accurate violation positions, taking into account all the other fixes, but we would need to take into account all the other fixes, and that sounds like a lot of work for something that I'm not sure many people would ever look at. |
|
Yes, there are potential ways to fix this and get it right. Yet, they don't seem to be easy. We will see if anyone is relying on these positions. I actually don't think so given that these locations are just wrong most of the time. For the moment, it's better to have a simpler output that is correct. |
Omit exact line and column information. Keep the internal logic available for a while in case people complain for good reasons. Then the change can be reverted easily.
Reasons behind this change: