all of the rules above are again kinda of stylistic (last one is already covered directly by typescript). If something is wrong, typescript will tell u during compile regardless whether you specify function return type explicitly or not.. I also depend on computer types in typescript (maybe thats why i think like this for linter with strict mode)
Well if you don't mind having the code written in a project not conform to code style rules, then a linter is of no value. You just might have a large variance in the way code is structured/ordered, variables are named, and other code style related things.
When I'm working on a project, I prefer to look at the code base and have it look like it was all written by the same person. A linter helps achieve this in my opinion.
This is also a tsconfig option. What use is eslint really? Tsconfig.json and .prettierrc cover most cases as far as I can tell. Is there one compelling use case for eslint?
all of the rules above are again kinda of stylistic (last one is already covered directly by typescript). If something is wrong, typescript will tell u during compile regardless whether you specify function return type explicitly or not.. I also depend on computer types in typescript (maybe thats why i think like this for linter with strict mode)
Well if you don't mind having the code written in a project not conform to code style rules, then a linter is of no value. You just might have a large variance in the way code is structured/ordered, variables are named, and other code style related things.
When I'm working on a project, I prefer to look at the code base and have it look like it was all written by the same person. A linter helps achieve this in my opinion.
And there's still things like no explicit any that can be enforced by the linter.
This is also a tsconfig option. What use is eslint really? Tsconfig.json and .prettierrc cover most cases as far as I can tell. Is there one compelling use case for eslint?
There are many eslint rules that arenβt covered by tsconfig options.