Description
This follows some thoughts I had with "The Maybe Future of Frontend Tooling" and picks up some use cases which aren't covered by the current (awesome!) language server plugin support.
Current state
-
The compiler has lint level checks like
noUnusedParametersornoUnusedLocals. -
TSLint deprecated support for
no-unused-variablebecause of that. -
Now issues like Add support for diagnostic severities #13408 were created so the TypeScript compiler only warns about unused variables and don't throw compiler errors.
-
That would be a nice feature in general, but it misses other useful linter features like auto-fixing linter warnings (e.g. removing unused variables).
-
(By the way... in TSLint v5 the deprecation message for
no-unused-variablewas removed, because the warning and auto-fix is so useful and not covered by TypeScript currently.) -
People would like to see unused imports in IDEs (see Suggestion: Show unused imports in VS Code Editor as grayed #8165).
-
Typings for libs can be shipped with the package itself and are referenced in the
typingsfield in thepackage.json. The lib itself can be written in TypeScript or not. -
Language server plugins aren't automatically picked up.
What I'd like to see
- It would be nice if linting would be a core feature of the language service - they don't stop compiling the source code and they have auto-fix ability.
- It would be nice if lib authors could publish linting rules which are automatically picked up by the language service (just like
typings). Two example use cases:- Say my lib
cool-libexports a functionfooin v1. In v2 it will be renamed tobar, so we deprecatefooand export abarwith v1. I could publishcool-libwith a linting rule which shows a deprecation warning forfoowhich then could be auto-fixed tobar. - A real world example (see content: ' ' generates invalid CSS threepointone/glamor#249): In glamor writing
{ content: '' }is not allowed. We can create a warning at runtime, but with a custom linting rule we can warn the developer while writing this code and auto-fix it to{ content: '""' }. - TypeScript itself could ship with more specific linting rules in the future which would help the average developer (e.g. show warnings for deprecated methods like
String.prototype.big().
- Say my lib
Update from August 2019
By now TypeScript support so called suggestions which allow fixes. This leverages the linter idea as a core of TypeScript even more in my opinion. TypeScript even gained several nice refactoring features (like renaming files and automatically update relevant paths) which I would like to call from inside of a linter rule.