![]() Fixing linting issues is not the fun part of coding. It requires a developer to go and try to fix it themselves, creating additional manual work. This makes it clunky to run in CI or as a pre-commit hook. ![]() Most of what ESLint enforces is not automatically fixable, unlike Prettier. This is too much unnecessary mental drain on everyone. Every time you bring on a new developer you are then opening up these decisions to question. Either that or you need a whole README devoted to why certain rules are enforced and others are not. As web developers we already suffer from decision fatigue, having to choose between frameworks, 3rd party libraries, state management, different styling options, REST vs GraphQL, build tools, etc.Īn example of ESLint decision fatigue from a real project:ĮSLint rules are often arbitrarily turned on/off based on people's opinion. It just ends up adding options, which we really need less of. It doesn't solve the stylistic flame war. The problem with ESLint is that it's too configurable. Especially with Airbnb's configuration, which tends to be very strict. In the past, I used ESLint heavily in my frontend projects. That means that any staged files will be Prettified when you commit using git. If you are working on a full-stack or multi-language team, you can use the pre-commit Python package to run Prettier as a pre-commit hook. If you are purely a frontend team, you can use husky and lint-staged. There are many ways to enforce Prettier on your team besides having everyone set it up in their IDE. Check out this Github repo for alternatives in other languages. Prettier is not the only code formatter out there. Leave that discussion and mental baggage to the Prettier team, I promise they've already given plenty of thought to what the best defaults are. The benefit of using them is already outweighed by the time you've wasted discussing it. While you may be right that God's intention for strings is to use double quotes, it really doesn't matter. We need to start valuing our time more and realize these discussions are a waste of time. Since we started using Prettier on my team, pull request reviews are much more effective and we're no longer having stylistic discussions every. While it's good that we care this much about the quality of our code, overall this is a huge waste of time. Opinionated formatters are great because they eliminate the ongoing flame war nerds and programmers love to have about code formatting. There is a strange pleasure in seeing your garbled JSX fit perfectly into place on save. Any modern IDE should have this capability. I strongly recommend you do the same if you haven't already. I use VSCode, so I setup all my projects to format on save. Isn't that simple? My settings are a bit opinionated so you can get by with even less! Enter fullscreen mode Exit fullscreen mode
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |