5 ms·

The debate for me is now eslint —-fix or prettier. I don’t get why people need more “control”. If it breaks code, then sure, I understand the reservation but in

The debate for me is now eslint —-fix or prettier. I don’t get why people need more “control”. If it breaks code, then sure, I understand the reservation but in 99% of cases, it just, “I don’t like how it breaks up my code”. Why care? At least, if you’re all using it, the diffs will be predictable and PRs can focus on what matters. //rant

crooked-v 3y ago
The answer is "both". Use ESLint for actual fixes and Prettier for formatting.
treve 3y ago
I can't remember the last time PR comments addressed minor formatting issues at all, in any language. If something is hard to grok it usually has to do with logic, not if there's a space between `if` and `(`.
- bluSCALE4 3y ago
  You're right, I more meant that if you don't format, your code sometimes becomes difficult to read and you become disincentivized to fix anything because git blame will point at you. I run into this all the time when people tell me, don't format the code because we won't know who did what. I get this even from senior devs as if using git blame and history is rocket science. If everyone stops bickering and just formats, all this noise goes away.
  - 8n4vidtmkvmk 3y ago
    If that's really an issue just reformat the whole code base once and be done with it.
    - rashkov 3y ago
      Yep, plus you can always do a git blame of the commit just before this happens. For example git blame a1b2c4 -- foo.js Where a1b2c4 is the commit hash. Could even tag the commit to make it more convenient: git tag beforeRefmt a1b2c4 git blame beforeRefmt —- foo.js and push the tag up for everyone to have access to it git push —-tags
spiderspace 3y ago
ESLint deprecated its formatting rules and recommends Prettier and dprint - https://eslint.org/blog/2023/10/deprecating-formatting-rules/ https://eslint.org/blog/2023/10/deprecating-formatting-rules...
- OJFord 3y ago
  Or stylistic eslint community plugin which started by forking the deprecated rules/plugins. It's the most promising option IMO, since unlike prettier they're actually receptive to making changes / adding config options that will allow making code and in particular diffs, err, prettier.
  - joks 3y ago
    Yeah the eslint stylistic plugin basically deprecated Prettier for all my purposes (+ my team just moved to it too.) I wish it could autofix line length warnings like Prettier but I understand the reasons why it doesn't and it's easy to manually fix those anyway.

crooked-v 3y ago

The answer is "both". Use ESLint for actual fixes and Prettier for formatting.

treve 3y ago

I can't remember the last time PR comments addressed minor formatting issues at all, in any language. If something is hard to grok it usually has to do with logic, not if there's a space between `if` and `(`.

bluSCALE4 3y ago
You're right, I more meant that if you don't format, your code sometimes becomes difficult to read and you become disincentivized to fix anything because git blame will point at you. I run into this all the time when people tell me, don't format the code because we won't know who did what. I get this even from senior devs as if using git blame and history is rocket science. If everyone stops bickering and just formats, all this noise goes away.
- 8n4vidtmkvmk 3y ago
  If that's really an issue just reformat the whole code base once and be done with it.
  - rashkov 3y ago
    Yep, plus you can always do a git blame of the commit just before this happens. For example git blame a1b2c4 -- foo.js Where a1b2c4 is the commit hash. Could even tag the commit to make it more convenient: git tag beforeRefmt a1b2c4 git blame beforeRefmt —- foo.js and push the tag up for everyone to have access to it git push —-tags

spiderspace 3y ago

ESLint deprecated its formatting rules and recommends Prettier and dprint - https://eslint.org/blog/2023/10/deprecating-formatting-rules/ https://eslint.org/blog/2023/10/deprecating-formatting-rules...

OJFord 3y ago
Or stylistic eslint community plugin which started by forking the deprecated rules/plugins. It's the most promising option IMO, since unlike prettier they're actually receptive to making changes / adding config options that will allow making code and in particular diffs, err, prettier.
- joks 3y ago
  Yeah the eslint stylistic plugin basically deprecated Prettier for all my purposes (+ my team just moved to it too.) I wish it could autofix line length warnings like Prettier but I understand the reasons why it doesn't and it's easy to manually fix those anyway.