chore: loosen up eslint rules

[FRSgit]

https://alokai.atlassian.net/browse/UST-1825

[changeset-bot]

⚠️ No Changeset found

Latest commit: d4b279a

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[Razz21]

I was wondering if wouldn't be feasible to provide each config there with a set of strict rules (enabled conditionally) which would enable some of these "blocking" rules.
These rules would be intended for a development, while for demos/ clients projects we would deliver configs with strict rules disabled (or even better - without strict enabled)

[FRSgit]

@Razz21 that proposal makes sense, I'll add it to our backlog!
Edit: added here: https://alokai.atlassian.net/browse/UST-1848

[bartoszherba]

Why do we change these rules?

[bartoszherba]

Changes like that affects the whole company. It will have a great impact on the code quality and it should be not merged in such task. I understand the problem of reducing warnings when we lint the code but the goal should be do align with the best possible set of rules that will help us maintain the code, not to remove rules to address the threshold requirement. Such changes deserves RFC with an explanation of why do we things like we do. Currently warns are mostly harmless and it is a shame that we ignore them in the first place. If we turn off relative rules it will be nothing more like turning your back to the problem.

[lsliwaradioluz]

Thank you for making that change. I never understood why we disallowed ordering functions by relevance and making good use of hoisting.

[lukasborawski]

Can we get use cases and reasoning? The statement that some rules are problematic is not so mature here. We need a wider discussion about these rules, some of them are a real pain in the ass, but at the same time, they're quite important, and someone decided to use them not on top of a hunch, right?

[FRSgit]

@lukasborawski @lsliwaradioluz @bartoszherba Sorry, I thought those rules will be rather insignificant for you.
If you could - please write here which ones can be merged into this repository in your opinion.

I'll move everything else into storefronts repo as I don't want to waste too much of your time on eslint-rules-related discussions 😄

Sorry again, should've pinged you for your opinion

[Razz21]

I think this package may miss @typescript-eslint package as a dependency. I receive errors when trying to override these rules in a repo where this package is not explicitly installed, event though it is a dependency of typescript-eslint already

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud