It is a framework-agnostic "batteries included" config that aims to enable as many plugins and rules as possible to make your code extremely consistent and robust. It uses Prettier code style and autoformats your code with eslint-plugin-prettier.
There are dozens of great ESLint plugins out there. Did you know that there is a plugin that can optimize your regexes for you? Or did you know that ESLint can validate *.json files? This config allows you to gain the power of all those awesome plugins with a single `npm install`.
Fun (and useful) fact: you can use typescript-eslint for linting your JavaScript code. That's right, you can take advantage of typescript-eslint's type-aware rules, like `@typescript-eslint/naming-convention` and `@typescript-eslint/prefer-optional-chain`, without the need to switch to writing TypeScript. Use the `hardcore/ts-for-js` config for that.
Also, did you know that when you enable an ESLint rule with "rule-name": "error", you don't get all the benefits the rule can provide? Many rules have advanced options that are disabled by default. For example, the `no-unneeded-ternary` rule has the `defaultAssignment` option that can enforce using `foo = bar || default` instead of `foo = bar ? bar : default`. And the `no-param-reassign` rule allows you to modify parameter properties by default, which is considered a bad practice. This config uses those stricter options whenever it makes sense.
Back in 2016, when I started compiling this config, it was helping me begin my JavaScript journey. I was using it on small projects, and it was helping me avoid many JavaScript pitfalls. Over the years it grew and proved itself as an extremely useful tool for all kinds of projects, both backend and frontend. Now, I can't imagine what I would do without it and how much more painful our code reviews would be. And I really want to avoid any kind of nitpicking in pull requests. Let ESLint catch (and most of the time autofix!) all problems early.
The funniest thing: 500 rules are still not enough. We still spend time in code reviews catching issues and inconsistencies, especially when there are new developers on the team. So, expect to see more and more plugins and rules in the config in the future.
Let me know what you think. Try it out. Suggest more plugins.
There are dozens of great ESLint plugins out there. Did you know that there is a plugin that can optimize your regexes for you? Or did you know that ESLint can validate *.json files? This config allows you to gain the power of all those awesome plugins with a single `npm install`.
Fun (and useful) fact: you can use typescript-eslint for linting your JavaScript code. That's right, you can take advantage of typescript-eslint's type-aware rules, like `@typescript-eslint/naming-convention` and `@typescript-eslint/prefer-optional-chain`, without the need to switch to writing TypeScript. Use the `hardcore/ts-for-js` config for that.
Also, did you know that when you enable an ESLint rule with "rule-name": "error", you don't get all the benefits the rule can provide? Many rules have advanced options that are disabled by default. For example, the `no-unneeded-ternary` rule has the `defaultAssignment` option that can enforce using `foo = bar || default` instead of `foo = bar ? bar : default`. And the `no-param-reassign` rule allows you to modify parameter properties by default, which is considered a bad practice. This config uses those stricter options whenever it makes sense.
Back in 2016, when I started compiling this config, it was helping me begin my JavaScript journey. I was using it on small projects, and it was helping me avoid many JavaScript pitfalls. Over the years it grew and proved itself as an extremely useful tool for all kinds of projects, both backend and frontend. Now, I can't imagine what I would do without it and how much more painful our code reviews would be. And I really want to avoid any kind of nitpicking in pull requests. Let ESLint catch (and most of the time autofix!) all problems early.
The funniest thing: 500 rules are still not enough. We still spend time in code reviews catching issues and inconsistencies, especially when there are new developers on the team. So, expect to see more and more plugins and rules in the config in the future.
Let me know what you think. Try it out. Suggest more plugins.