wsl v5 - a complete rewrite ✍️
#169
Conversation
|
@ldez Feel free to give input on this PR. I don't expect any feedback but you mentioned you had some thoughts and/or opinions and I gladly hear them all! Especially anything that affects I'm not in a rush merging this so don't stress getting to this and again, I'm not expecting anything so this is more if you had any interest! |
|
I will review it tomorrow. |
|
I'm still on the topic, but this interrogating me on a larger topic of major versions of linters. |
No need to say sorry and no rush, I see you're active every day and with more important topics! If you feel this adds complex scope to Take your time and we'll see if/when you get to this! |
@ldez Do you want to open a discussion around this in the Thinking if your concerns are around those bits maybe no need to do any form of review, I don't think the code matters if the effect on Also as mentioned before just because I merge this it doesn't mean we have to immediately bump the major version in |
|
I'm gonna go ahead and merge this and change the default branch. This doesn't mean that I will do a 5.0 release just now, but I'll do some more testing and maybe get some feedback before I do so. If no issues are reported we can start the migration in The plan will likely be to introduce a new major version change flow where v5 will be added as a new linter and the old |
I never liked how the code turned out. In fact, I really don't like it. It's hard to follow, huge scopes, weird names. When I did the initial diagnostic messages I barely knew about the AST and different types and I never tested the code on real big projects.
Back in 2023 I removed all the code and started from scratch, didn't really know what to expect. I did some POC starting with the
wslfoundation and empty leading and trailing whitespaces. I then picked this up again sometime 2024 and did tiny pieces here and there. In 2025 I started to get back to this more regularly although still with a slow pace.I'm now at a place where I think I've covered all use-cases and all configuration and intentions. I think the code is easier to maintain and hopefully it will be easier to change as well. From a user perspective, the important changes are:
ifstatements? Turn them off! Only care aboutreturnandbranch? Just enable those! Pluswslspecific checks that was previously unique bools like strict append. In fact, you can now disable all checks and get no diagnostics at all.deferhacks.sendor complex values assigned to declarations.The only considerations left as of now is:
AllowAssignAndCallCuddlebe kept and converted toCheckAssignExpr? (see e2fee7d)golangci-lintusers?