I just released a large release for
elm-review. I decided to split the announcement into 2 parts. This first part focuses on the large performance improvements done to
elm-review’s automatic fix feature.
I hope you’ll enjoy the changes as much as I will!
This looks great!
Thinking about how I would want to go about fixing up a codebase, I would want to follow this procedure:
- Pick one rule with violations
- Fix all violations, ensuring that no violations were introduced for rules that have no violations
- Commit these changes together
- Repeat until there are no more rules with violations
The --fix-limit flag might help facilitate this, but I think the ideal tool would make this process easy to do.
With the massive speed improvements I put in some work to have us running more rules at work. I can say that it’s been quite easy so far to delete thousands of lines of code without worry or issue.
@dta I agree with your general procedure, but I would like to know which pain-point you’re having with
elm-review in what you’re describing. I don’t feel like this is a problem for me, so I’d be curious to know.
You can enable rules one at a time. Especially for rules that provide fixes, doing this with
--fix-all should be quite straightforward. For rules that don’t provide fixes,
elm-review suppress --help can be quite helpful, though it will obviously require some manual work.
Enabling the rules one at a time exactly solves my use case! I think I was confused by
--fix-all not necessarily fixing all.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.