typescript-eslint VS eslint-stylistic

TypeScript Best Practices

Here’s some relevant discussion about some of the footguns:

https://github.com/typescript-eslint/typescript-eslint/issue...

https://github.com/tc39/proposal-explicit-resource-managemen...

I imagine there will eventually be lint rules for this somewhere and many of those using such a modern feature are likely to be using static analysis via eslint to help mitigate the risks here, but until it’s more established and understood and lint rules are fleshed out and widely adopted, there is risk here for sure.

Seems a bit like popular lint library maintainers are overly wary to add rules before it’s better understood through wider adoption and potential adopters are wary of using it until footguns are mitigated — not quite a standstill but maybe not great either

However, I prefer more thorough rules like checking unused type imports or type narrowing problems. In order to enable these checks, we need to tweak eslint.config.js. I prefer simply adding recommendedTypeChecked config to the project. Don't forget that you also need to adapt parserOptions to this change.

EsLint: New to ESLint? It helps you write better JavaScript and TypeScript. https://typescript-eslint.io/

For ESLint + TypeScript ESLint, with the new flat config eslint.config.js:

Typescript-eslint can assist in this task. This tool helps identify all instances of unsafe any usage. Specifically, all usages of JSON.parse can be found and it can be ensured that the received data's format is checked. More about getting rid of the any type in a codebase can be read in the article Making TypeScript Truly "Strongly Typed".

> Only lint files that have changed? How hard that is?

Quite hard, especially since type-aware rules from e.g. https://typescript-eslint.io/ mean that changing the type of a variable in file A can break your code in file B, even if file B hasn't changed.

The article only touches this: when converting to TypeScript, `any` is useful, but in the end you don't want this type in your codebase - so don't forget to use typescript-eslint [0] and turn on those no-unsafe-* rules which guard against `any` leaking into your code.

[0] https://github.com/typescript-eslint/typescript-eslint

@stylistic/eslint can be configured to pretty much replicate prettier's behaviour, but I'm an all or nothing guy. If I'm going to add an extensive plugin I'd like to use it properly, replacing my react and typescript rules with it as they recommend. I will probably get round to this when I have the time, updating my core eslint config

The npm package eslint-config-prettier eventually disables any ESLint rules dealing with code formatting to avoid conflicts with Prettier. You can see this with the handy ESLint Config Inspector: The second option is to use ESLint Stylistic. The primary focus of this project is on all stylistic rules including code formatting. This project was initiated as ESLint and typescript-eslint teams decided to deprecate formatting/stylistic-related rules.

Perhaps some polyfills are required regardless, see this discussion here: https://github.com/eslint-stylistic/eslint-stylistic/issues/43