infra(deps): add eslint unicorn

[Shinigami92]

This PR adds https://github.com/sindresorhus/eslint-plugin-unicorn to out eslint configuration

For now this is just the start of using this huge improvement-driven eslint plugin

I will do individual PRs for each rule, so the review process can be optimized and also individual rules can be discussed if needed

---

there is a PR that is an approximation of what it looks like when all is finished #2417

• chore: add eslint unicorn #2417

[codecov]

Codecov Report

Merging #2418 (793ab79) into next (c0386ac) will decrease coverage by 0.01%.
The diff coverage is n/a.

Additional details and impacted files

@@            Coverage Diff             @@
##             next    #2418      +/-   ##
==========================================
- Coverage   99.59%   99.59%   -0.01%     
==========================================
  Files        2823     2823              
  Lines      255523   255523              
  Branches     1107     1105       -2     
==========================================
- Hits       254488   254480       -8     
- Misses       1007     1015       +8     
  Partials       28       28              

see 1 file with indirect coverage changes

[ST-DDT]

This PR looks good to me, but I'm not sure whether we actually need it.

[Shinigami92]

This PR looks good to me, but I'm not sure whether we actually need it.

IMO we should definitely use eslint-plugin-unicorn, because you already asked for "is there a lint rule for XY" here #2284 (comment)

and secondly: I'm sick of getting asked such question, so I now try to bring forward more linting to prevent such questions proactively

[xDivisionByZerox]

I'm with @ST-DDT here. While this is cool and all, what is the actual value we gain from this? I've seen people go absolutly crazy over static code analysis and I fear that we might run into one of those rabbit holes here as well. If one of those rules is actually helpful I'm here for enabling them, but do we really need all of them? I'll have read into the explaination why we should use each rule but that will take a while.

[xDivisionByZerox]

[...] I'm sick of getting asked such question, so I now try to bring forward more linting to prevent such questions proactively

I'm sick of the lack of design patterns getting used in this library to ensure code readabilty and maintainablity, but I was getting shut down as it is "kind of overengineered". How is "proactively" disallowing certain programming styles though static code analysis not overengineered tho?

[ST-DDT]

This PR looks good to me, but I'm not sure whether we actually need it.

IMO we should definitely use eslint-plugin-unicorn, because you already asked for "is there a lint rule for XY" here #2284 (comment)

and secondly: I'm sick of getting asked such question, so I now try to bring forward more linting to prevent such questions proactively

I'm sorry.

[Shinigami92]

This PR looks good to me, but I'm not sure whether we actually need it.

IMO we should definitely use eslint-plugin-unicorn, because you already asked for "is there a lint rule for XY" here #2284 (comment)
and secondly: I'm sick of getting asked such question, so I now try to bring forward more linting to prevent such questions proactively

I'm sorry.

Accepted 🙂

Now I started to put a whole half day already to find a way to ensure a modern, uniform, stable code base, so there is no much place for doing it this way or that way
even some performance improvements are uncovered from that when we go this route long term
remember that eslint is to reduce load of maintainers and put the review step into un-biased non-human automation

it's a bit like the script, generation of locale files and auto-generating the docs

[matthewmayer]

Don't take this the wrong way, but i feel that we do spend a lot of time debating on adding more and more lint rules; and although the goals of a more modern and consistent codebase are noble, this shouldn't come at the expense of actually working on new features and fixing bugs.

[matthewmayer]

Obviously its partly personal preference, but i would much rather be brainstorming on adding a food module (1593) or figuring out steps towards solving bundle shaking (1791) than debating precisely when to use spread syntax :D

[Shinigami92]

Don't take this the wrong way, but i feel that we do spend a lot of time debating on adding more and more lint rules; and although the goals of a more modern and consistent codebase are noble, this shouldn't come at the expense of actually working on new features and fixing bugs.

Good that I'm not the only developer contributing to this project and stuff can be done in parallel

Obviously its partly personal preference, but i would much rather be brainstorming on adding a food module (1593) or figuring out steps towards solving bundle shaking (1791) than debating precisely when to use spread syntax :D

Feel absolutely free to do that, I don't hold you back
But I'm glad we are on the same side: "stop debating precisely when to use spread syntax", just let the linter do its job and use the eslint fixer
No more code review debation, no more personal preference, this is exactly what I'm trying to solve here

It's right now consuming a lot of my time while doing reviews to make up argues why something should be this or that way
Now eslint is telling you and you even have documentation by the individual plugins and you can just jump with only one mouseclick from the hover-tooltip to their docs and learn why something is better over the other
example: https://github.com/sindresorhus/eslint-plugin-unicorn/blob/main/docs/rules/prefer-array-find.md

Array#find() breaks the loop as soon as it finds a match and doesn't create a new array.

just by applying this lint rule, we get not even stylistic choices, but even performance-fixes

[ST-DDT]

Team Decision

ST-DDT will take over this PR and check whether all recommended rules or individual rules are shorter.