eslint-plugin-unicorn VS XO

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

Usually you would pick a config you like and set it up for your project, notable ones are already mentioned but I'll mention more:

- xo https://github.com/xojs/xo

You might enjoy `xo` :) https://github.com/xojs/xo

XO

The developer told me we could not do that because the linter we are using. (XO)[https://github.com/xojs/xo] started complaining.

Real world example: you are using create-react-app, and you want to also to use xo, as both come with their own version of ESLint pre-installed, you could end up with 2 ESLint installed.

One of the biggest hassles to update was the linter we are using: XO, which is a very opinionated, but customizable linter base on ESlint.

Projects: awesome, awesome-nodejs, avajs/ava, xojs/xo