[FEATURE REQUEST] Modernize ESLint
elliot-huffman opened this issue · comments
Is your feature request related to a problem? If so, please give a brief summary of the problem and how the feature would resolve it
ESLint is moving to the new flat file config spec and the current *eslint* file set that you are using is deprecated.
Additionally, are all the rules that are currently set the set of rules that you want to keep?
You don't have the typed strict rules enabled which can pair down your existing ruleset by having the best practices enforced by the linter automatically without having to explicitly configure every rule.
Also, some of your style rules are not natively supported by VS Code auto formatting, would you like to align your linting config to VS Code's auto formatting for: spaces, commas, brackets, new line and other built-in formatters?
I can closely match your current styles, there are just some semi colons that aren't fully supported in VS Code.
We can also enforce more auto styling in VS Code if this is something you want to do as you only do a subset of stylization at the moment.
Describe the preferred solution
- Migrate to the flat file config spec.
- Modernize/review lint rules
- Migrate from custom spec to ruleset
Describe alternatives you've considered
Not updating deps? (bad practice)
Additional context
https://typescript-eslint.io/blog/announcing-typescript-eslint-v7
https://eslint.org/blog/2024/04/eslint-v9.0.0-released/
Rulesets:
https://typescript-eslint.io/getting-started/#additional-configs
Reference Documentations/Specifications
https://eslint.org/docs/latest/use/configure/configuration-files
All of this sounds sensible to me! Looking forward to see pull requests for this coming in. 🙇♂️
ESLint is moving to the new flat file config spec and the current
*eslint*file set that you are using is deprecated.
👍
Additionally, are all the rules that are currently set the set of rules that you want to keep?
You don't have the typed strict rules enabled which can pair down your existing ruleset by having the best practices enforced by the linter automatically without having to explicitly configure every rule.
I don't quite remember why I enabled specific rules instead of using one of the presets. I guess switching to a pre-set could help me remember why we didn't use one in the first place. 😅
Also, some of your style rules are not natively supported by VS Code auto formatting, would you like to align your linting config to VS Code's auto formatting for:
spaces,commas,brackets,new lineand other built-in formatters?
Yeah, if we can do that, that would be great. Would definitely make it easier for people that use VS Code / Codespaces to work on tedious.
I have the configs converted and wow, after enabling the recommended rule sets, there are a lot of fixes that have been bubbled up.
I am going to break this into two parts.
The ES Lint config update and the rules fixes.
Please see the below for work I am gonna start on:
It looks like the data is not properly typed throughout the project.
The majority of errors are unsafe 'any' assignments, which in most cases is lack of generics configurations or someone suppressing type checking by placing an any type on something that should have unknown or the correct type instead. any could be used to suppress type checking to hide stuff or to reduce the amount of validation that is required on an object, and in these cases, this is usually a security risk due to incorrect or assumed data.
Looks like I will also have to convert some files that are currently JavaScript files to typescript, I see a few in the tests folder.
PR Part 1 is up, let me know what you all think #1631 :-)
The linting fixes will be introduced as additional commits to it, hence the draft state.
Got the error count down to ~150 with 50 auto-fixable.
The config is now almost identical to your original config. It appears that some of the new issues that are bubbling up are due to updated rulesets because of the updated packages.
These issues appear to be correctly identified by the linting system.