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

[Maintenance Task] - Review ESLint settings and fix linting issues #3224

Closed
matthew-dean opened this issue Jun 21, 2018 · 6 comments · Fixed by #3709
Closed

[Maintenance Task] - Review ESLint settings and fix linting issues #3224

matthew-dean opened this issue Jun 21, 2018 · 6 comments · Fixed by #3709

Comments

@matthew-dean
Copy link
Member

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.

@umuur
Copy link

umuur commented Jan 18, 2021

Hi there, i'd like to grab this!

@matthew-dean
Copy link
Member Author

@umuur Go for it!

@umuur
Copy link

umuur commented Jan 19, 2021

@matthew-dean Do we want to keep current eslint configuration?
I'm not sure having TypeScript as a parser and plugin is necessary.

@matthew-dean
Copy link
Member Author

@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.

@matthew-dean
Copy link
Member Author

@umuur

By the way, anywhere where you can add JSDoc comments with proper types on params, please add them!

@umuur
Copy link

umuur commented Jan 20, 2021

@matthew-dean thank you for the detailed comments! Will let you know about the updates.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants