General > Improve Linting

[JacobHeldt]

Why

Many developers are encountering eslint errors when pushing changes. The current rules are perceived as excessively strict, leading to the addition of folders to the .eslintignore file and the frequent use of git commit --no-verify -m, which are both suboptimal practices.

Tasks

• Investigate the linting rules and make them less strict.
• Consult with Jacob and other contributors for feedback.
• Remove files and folders from .eslintignore where possible.
• Resolve remaining linting errors.

[rayvego]

Hey, I took a look into this. The errors that eslint is giving are mostly sensible. Some of these errors are described below: (I mean if you have defined that you want it in eslint then you have to follow it...)

• camelCase
• '...' is missing in props validation ("..." = classname/align/etc)
• consistent-type-imports
• consistent-type-definitions
• filenames/match-regex
• returning a void expression from an arrow function shorthand

Here are some eslint rules that can be set as "warn" instead of "error" as they may be neglected

Unsafe Type Handling (@typescript-eslint/no-unsafe-*)

• @typescript-eslint/no-unsafe-assignment: This warns when you assign a value of type any (meaning it could be anything) to a variable with a more specific type (e.g., string, number, etc.). This can be risky because TypeScript won't be able to fully check if the assigned value is compatible with the expected type. Setting this as warn instead of error.
• @typescript-eslint/no-unsafe-call: This warns when you call a function whose parameters or return type are of type any. Since the types are unknown, the function could potentially receive or return values that lead to unexpected behavior at runtime. Setting this as warn instead of error.
• @typescript-eslint/no-unsafe-member-access: This warns when you try to access a property or method on a value of type any. It's similar to no-unsafe-call, but specifically for accessing members (properties or methods). **Setting this as warn instead of error.

Misused Promises (@typescript-eslint/no-misused-promises, @typescript-eslint/no-floating-promises)

• @typescript-eslint/no-floating-promises: This warns about promises that are not handled correctly, meaning they are not awaited or have their results or errors handled using .then() or .catch(). Unhandled promises can lead to errors that are hard to debug. Setting this as warn instead of error as many times in react hooks we don't put a .then() or a .catch().
• @typescript-eslint/no-misused-promises: This warns about using a promise-returning function in a context that expects a non-promise value. For example, passing a promise to an event handler that expects a void function. This is kept on as if it is defied then the purpose of Typescript is defined.

Import Deprecation (import/no-deprecated)

• import/no-deprecated: This warns about importing modules or members of modules that have been marked as deprecated. Deprecated code is likely to be removed in future versions, so using it can make your code harder to maintain. Setting this as warn instead of error.

Based on this, we can decide which rules to update and for which rules we need to refactor the codebase.

[zaibutcooler]

removed a lot of the extensions for now.

[zaibutcooler]

anyone still having issues?