You must log in or register to comment.
- 1 year
I used to have my vim set up to trim excess whitespace on write.
I had no idea how many errant diff’s that would generate, I had to turn it off.
- 1 year
The right balance on this is to set it up to only trim whitespace on lines that you have edited, and only on-save.
Emacs has ws-butler for that behavior: https://github.com/lewang/ws-butler
- 1 year
That History section is exactly what happened to me
I’ll have to see if there’s a nvim equivalent, or if I can make my own
- 1 year
Yeah, you generally just want the same auto-stuff done as would be enforced in CI anyway.
… all the other stuff you could fix but wind up just ignoring because your team ignores it will just glare at you until you sneak it in somehow
- pppirate@lemmy.dbzer0.comEnglish1 year
i have prettier auto formatting on save (but also use vim auto format)
- 1 year
I’ve been trying to pair down my extensions, so I’ve been using ale’s fixers to do formatting.
I’m not a huge fan though, I’ll probably go back to vim auto format.
- 1 year
The linter runs automatically on every commit and blocks merges if it fails. Try again
- 1 year
If there’s a linter with such opinionated rules there should also be a pre-commit hook that auto-formats accordingly.
- 1 year
That’s up to each individual developer’s own setup. But hooks are a way to ensure uniformity since they apply to all commits.
Why would it be on each dev to setup?
Your repo can, and should, include workspace settings for major editors that provide a uniform experience for anyone onboarded to the platform.
I agree that precommit hooks are good for uniformity. But slow pre commit hooks are frustrating, they are also often turned off. Your CI will always be the last gatekeeper for linting/formatting rules regardless.
Making precommit hooks slower means more devs disable them, which is the opposite of what you want. Save them for simple, read, checks and validations that can run in < 1s for even huge changesets.
That’s not a linting problem that’s a formatting problem.
That project should have automatic formatting on save setup.
Linters are not necessarily formatters they’re solving two different problems and are becoming increasingly separated in their toolset.
- pppirate@lemmy.dbzer0.comEnglish1 year
for me, it’s rather the tests in the pipelines rather than linting, which happens while I’m writing code
