exer_log
exer_log copied to clipboard
EXERLOG
[chore] - add linting support
Hey, always been lurking in your videos and took a quick look at the codebase. I think the net biggest improvement will be done by just adding lints.
There are a couple of different approaches but new projects use flutter_lints which does the job quite well. This would just be a tedius change as there will probably be a lot of small issues that needs to be resolved but should still be very simple and straight forward.
Keep making great videos 😊
Thanks! Great idea, I'll have a look at that. I've heard of lints but never used it so I'll have to learn!
@KalleHallden Just some unsolicited advice, I'd block any actual work on features etc by this and #10 and #9. The amount of merge conflicts caused by such large project wide changes would probably turn off anybody who is trying to contribute.
Also, somewhere down the road you should probably have pre-commit or GitHub Actions run these lints automatically on all commits and PRs. Ideally such workflows are part of your repository template. There are many examples online on how to do this.
@DanielNoord Yeah I think that would be a good idea. But I don't quite understand what you mean when you write '...block any actual work on features etc by this and #10 and #9'? Do you mean block all issues except this one (#3) and 10 and 9? Or do you mean the opposite hehe
I have zero experience running an open source project so I really have no idea what I'm doing at this point
@DanielNoord Yeah I think that would be a good idea. But I don't quite understand what you mean when you write '...block any actual work on features etc by this and #10 and #9'? Do you mean block all issues except this one (#3) and 10 and 9? Or do you mean the opposite hehe
Yeah, the first option. Basically, if stuff gets moved around or every line gets changed because of linting (for example because the linter wants to use ' instead of ") it will be very difficult to then subsequently merge any feature branches into main.
Ideally, you should do some of this yourself as it is much easier to "trust" that way. Having unknown contributors move around all your files can be risky as they could easily include some additional code somewhere. #3 has a pretty clear structure so one commit by you that follows it would be a great first step.
I have zero experience running an open source project so I really have no idea what I'm doing at this point
This is also relevant for personal projects. Moving or linting the complete project should ideally happen when you have little feature branches that are not yet in main as it will always lead to merging headaches.
In order to keep this issue moving I've created a pull request containing a first proposal for some linter rules. I haven't actually applied the rules to the code but it might give you a better idea @KalleHallden.
@BertVanMieghem I can't find your PR. We should finish implementing this.
@KalleHallden we added support for linter in this https://github.com/EXERLOG/exer_log/pull/191 so I think we can close this issue if you want :)
