Eslint rules

My preferences and things I've found useful.

I was distracted from writing another dynamic programming post when I noticed an unused import without a squiggly red line under it. I dove in to the eslint config to correct the error, but I couldn't just stop there. I'd like to get my thoughts down on the rules I use and why I use them.

"jsx-quotes": ["error", "prefer-double"]

Because of contractions (it's, don't, etc.). Plain and simple. I don't want to escape single quotes in my strings for contractions.

"@typescript-eslint/indent": "off"

Eslint shouldn't be in charge of the indentation rules anyways. That's a job for a formatter like prettier.

"curly": ["error", "all"]

It's tempting to want to allow these for "guard clauses," but it's always less clear than an if/else statement. You trade a few extra lines for clarity. That's worth it to me.

"arrow-body-style": ["error", "always"]

I've made the mistake of thinking I was returning an object when I wasn't a few times. Enough times that I don't make that mistake anymore personally. However, when my friend was learning to code, he also made the mistake multiple times. It became clear to me then that it was the wrong way to write the code. Writing arrow functions without curly braces is irresponsible coding.

"no-else-return": "off"

I have not yet found a rule that would enforce an else case with every if. I'm also not sure how such a rule would effect my code; especially some useEffect()s. That being said, it always makes the code more clear. Combining this practice, along with always putting the failing condition first, leaves no room for confusion. Maybe I'll try to write that rule one day.

"no-console": ["error", { "allow": ["warn", "error"] }]

Simple: no console.log statements should make it out of development.

"use-encapsulation/prefer-custom-hooks": ["error", { "allow": ["useMemo"] }]

I think I came across this in the Bytes newsletter and the guy makes a fantastic case for it here: https://kyleshevlin.com/use-encapsulation.

"validate-jsx-nesting/no-invalid-jsx-nesting": "error"

The browser attempts to fix invalid nesting, but it's not always perfect. This rule is a good way to catch those errors before they make it to the browser.

"import/prefer-default-export": "off"

The 'default' export was a mistake. It's much better and more consistent to use named exports. At the very least, you can track the name of the import to the name of the export.

"simple-import-sort/imports": "error", "simple-import-sort/exports": "error"

I found myself sorting these manually. Ideally, it will help group the local imports so it's easier to tell what's coming from a 3rd party dependency and what's not.