Stricten Eslint rules #14282
Labels
frontend
quality/code
Violations from current rules for code, best practices, etc. Or just bad code.
status/ready-for-specification
Status: Used for issues that are ready for functional decription og detailed design.
team/studio-core
team/studio-domain1
team/studio-domain2
As the team is growing, we need to stricten our Eslint rules in order to ensure that the code stays consistent and conforms with our principles.
We already have some open issues for particular rules:
Here are some other rules that we should consider:
max-depth
, but for functions used as parametersany
typeref
is forwarded when usingforwardRef
useState
The rules may be applied one by one and to one package at a time if it turns out that they require a lot of changes in the code.
The text was updated successfully, but these errors were encountered: