-
Notifications
You must be signed in to change notification settings - Fork 176
fix all the remaining eslint warnings #545
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
Conversation
commit: |
|
||
"@typescript-eslint/unbound-method": "error", | ||
|
||
"@typescript-eslint/no-non-null-assertion": "warn", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am personally not a fan of this one 😅
if someone uses a non-null assertion I think that's generally for a good reason so having to add an eslint disabling comment for it feels very unnecessary/annoying to me 🤷
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I'm fine with this
We just need to verify on every PR to make sure it's not used unwisely
"sonarjs/elseif-without-else": "warn", | ||
"sonarjs/no-duplicate-string": "warn", | ||
"sonarjs/cognitive-complexity": "warn", | ||
"sonarjs/cognitive-complexity": ["warn", 35], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
35
allows most functions in the codebase, I could just add disabling comment to each one instead if preferred (there were around 10-ish or something I think)
I did not attempt on splitting the functions as I am not really familiar with the codebase here (but I am happy to give it a go if you want 🙂)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree.
I need to take a closer look at the PR later today, I remember that there was a reason that it was this order. Might be old code
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry it was old code, there was a reason for the order back when we used multiple file for cache, but now that we have a single file it doesn't matter
}; | ||
} | ||
|
||
const indexHandler = "index.hander"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a typo here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sorry 😓
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No problem
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sorry 😓
Typos happens to everyone. Your PR made the code more DRY and easier to read. Great work ⭐️
continuation from #544 🙂
Some changes might be controversial I am happy to adjust them any way you prefer, I just applied what I thought more sensible and/or my personal preference 🙂