-
-
Notifications
You must be signed in to change notification settings - Fork 159
Conversation
90e8053
to
d7e380b
Compare
so, I've ran a quick count on the errors using
(edit: the data above is only showing the typescript-eslint related entries, the "regular" eslint rules are missing, just if anyones wondering, why the numbers don't add up). The "no explicit any" error is not that bad after all – I though it would've been a higher count, after doing a first scroll through :-D @eliandoran what do you think? |
quick aside, regarding failing CI: looks like it will land soon though :-) |
ok, it has been released -> will update and rebase the branch accordingly later this evening: |
e24b479
to
6fb6ea9
Compare
6622965
to
a8dcf9d
Compare
PR ready for a first start :-) |
77d9423
to
b568307
Compare
rules will need some finetuning still
purposely *not* named as dev:eslint, just to "decouple" the script from eslint, in case there ever is the need to change that :-)
For TS projects this is already enforced by tsc, see: https://eslint.org/docs/latest/rules/no-undef#handled_by_typescript
using it is not recommended for ts-eslint: https://typescript-eslint.io/troubleshooting/faqs/eslint#can-i-use-eslints---cache-with-typescript-eslint
this is already used across codebase: using "_" as placeholder for deliberately unused vars (e.g. when destructuring arrays)
b568307
to
2c7a25b
Compare
Hi,
this PR adds an initial eslint configuration that we can use for linting our code base.
https://typescript-eslint.io/
It still needs some rule refinement for our current stage, because we still have lots of "any" types, which it complains about with the default rules
majority is complains about use of "any".
I'll likely work on the rules first, before marking the PR as ready :-)closes TriliumNext/Trilium#5524closes TriliumNext/Trilium#5026