A while ago I switched the project from JSHint to ESLint (the latter being better-maintained and offering more features). However, I set many of the settings as warnings because I didn't have time to address potential issues. Nor did I really have time to tweak linting for settings that make the code more maintainable.
So, the task would essentially be to look at ESLint warnings, and see what can be safely addressed. (For example, a lot of the ==
equality warnings may not be "fixable" to ===
without testing for every value that passes through that check.) It would be helpful to also set warnings for things to address in the future / ongoing, such as enforcing JSDoc documentation.
Hi there, i'd like to grab this!
@umuur Go for it!
@matthew-dean Do we want to keep current eslint configuration?
I'm not sure having TypeScript as a parser and plugin is necessary.
@umuur
Do we want to keep current eslint configuration?
It depends. If you want to make alterations that don't change code formatting, that's fine. But as far as warnings, IMO those are all valid warnings and we either want to address them, or leave a code comment about disabled eslint and (most importantly) why it's not valid there.
Do we want to keep current eslint configuration?
Even though the codebase does not use TypeScript yet, in my experience, it does a better job transpiling than Babel. In terms of ESLint.... 馃 yes you're right it's not technically needed until there's code in TypeScript. I probably did that in anticipation of converting the codebase to TS, but now I don't know if / when that will happen.
@umuur
By the way, anywhere where you can add JSDoc comments with proper types on params, please add them!
@matthew-dean thank you for the detailed comments! Will let you know about the updates.