Skip to content

Revisit our Typescript linting rules #714

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

Open
1 of 8 tasks
pokey opened this issue Jun 1, 2022 · 4 comments
Open
1 of 8 tasks

Revisit our Typescript linting rules #714

pokey opened this issue Jun 1, 2022 · 4 comments
Labels
code quality Improvements to code quality

Comments

@pokey
Copy link
Member

pokey commented Jun 1, 2022

Originally posted by @pokey in #705 (comment)

@auscompgeek
Copy link
Member

I don't see where our eslintrc extends typescript-eslint/recommended. Maybe we have a whole bunch of lints and we just haven't noticed 👀

@pokey pokey added the code quality Improvements to code quality label Jun 6, 2022
@pokey pokey changed the title Add no-unnecessary-type-assertion to typescript lint rules Revisit our Typescript linting rules Jun 8, 2022
@pokey
Copy link
Member Author

pokey commented Jun 8, 2022

Updated description to be more general

@auscompgeek
Copy link
Member

explicit-function-return-type

Should we use explicit-module-boundary-types rather than explicit-function-return-type?

@auscompgeek auscompgeek removed their assignment Dec 15, 2022
@auscompgeek
Copy link
Member

Unassigning myself because I realistically won't have time to enable more lint rules.

It'll be good to consider the lint rules that use type information, but we should consider how enabling type checking in linting affects the linter performance.

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

No branches or pull requests

2 participants