Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stricten Eslint rules #14282

Open
TomasEng opened this issue Dec 13, 2024 · 0 comments
Open

Stricten Eslint rules #14282

TomasEng opened this issue Dec 13, 2024 · 0 comments
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

Comments

@TomasEng
Copy link
Contributor

TomasEng commented Dec 13, 2024

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:

Plugin Rule What to use it for
max-params Never exceed three parameters in a function
max-depth Only allow one level of abstraction
max-nested-callbacks Similar to max-depth, but for functions used as parameters
max-lines Split up in several files when a file becomes too large
max-lines-per-function Split up in several functions when a function becomes too large
typescript-eslint no-explicit-any Avoid using the any type
typescript-eslint typedef Require type annotations in certain places
eslint-plugin-react function-component-definition Enforce components to be written as function declarations
eslint-plugin-react forward-ref-uses-ref Ensure that the ref is forwarded when using forwardRef
eslint-plugin-react hook-use-state Enforce the naming convention for the return value of useState
eslint-plugin-import no-cycle Avoid circular dependencies

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.

@TomasEng TomasEng converted this from a draft issue Dec 13, 2024
@TomasEng TomasEng added quality/code Violations from current rules for code, best practices, etc. Or just bad code. frontend team/studio-domain1 team/studio-domain2 team/studio-core status/ready-for-specification Status: Used for issues that are ready for functional decription og detailed design. labels Dec 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
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
Projects
Status: No status
Development

No branches or pull requests

1 participant