
Show HN: eslint-config-hardcore – 17 plugins, 500 rules, and counting - EvgenyOrekhov
https://github.com/EvgenyOrekhov/eslint-config-hardcore
======
EvgenyOrekhov
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.

