eslint-plugin-proper-arrows VS eslint-plugin-unicorn

In any case, to the point of keeping arrow functions readable, I think there's a wide variety of opinions on what is "readable" => usage and not. So, I wrote a fairly-configurable ESLint rule called "proper-arrows" to try to help wrangle most of the various ways => are used that can harm readability. I'd encourage you to have your team pick the dos/donts of => and enforce that style with a linter.

I recently scanned out codebase with https://github.com/sindresorhus/eslint-plugin-unicorn/blob/main/docs/rules/prefer-set-has.md and found many instances of potential "accidentally quadratic" uses of array.includes instead. gas a nice autofix to convert to set. there are some fun and sometimes useful lint rules out there...

There’s an ESLint rule for that (albeit in a plugin)

Many popular eslint configs have even introduce rules to warn on its usage for these very reasons.

eslint-plugin-unicorn

I find eslint-plugin-unicorn package pretty useful for updating old code. With IE11 dead and NodeJS v12 LTS sunsetting soon, it's a brave new world.

Default parameters should not be passed to a function through an object literal. The foo = {a: false} parameter works fine if only used with one option. As soon as additional options are added, you risk replacing the whole foo = {a: false, b: true} object when passing only one option: {a: true}. For this reason, object destructuring should be used instead. Linter rule