Feature Request: Linting should be a core feature of the language server

[donaldpipowitch]

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 noUnusedParameters or noUnusedLocals.

• TSLint deprecated support for no-unused-variable because 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-variable was 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 typings field in the package.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-lib exports a function foo in v1. In v2 it will be renamed to bar, so we deprecate foo and export a bar with v1. I could publish cool-lib with a linting rule which shows a deprecation warning for foo which then could be auto-fixed to bar.
  • 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().

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.

[donaldpipowitch]

Just fell into a rabbit hole.

• It looks like no-unused-variable isn't deprecated in TSLint anymore?
• I enabled it in our TSLint config.
• The TSLint VS Code extension can't use TSLint rules which need a type check.
• There is a new tslint-language-service which enables type check for TSLint rules.
• This tslint-language-service only works with a new TSLint VS Code extension.
• This seems to work for all TSLint rules, but no-unused-variable (see The implementation of the 'no-unused-variable' rule breaks the tslint language service plugin palantir/tslint#2649).

Update from August 2019

• The no-unused-variable rule is deprecated again in TSLint.
• This was done, because TypeScript 2.9 introduced an suggestions feature for unused variables with the capability to remove this variable. When --noUnusedLocals/--noUnusedParameters is disabled, add suggestions instead of errors #22361
• However AFAIK there is currently no simple migration path as I couldn't found a simple example to use this TS2.9 feature in a standalone script (see Add support for diagnostic severities #13408 (comment)) to run it in CI for example.

Just wanted to illustrate the current state of tooling around this and the rough edges. Thanks for the work so far. 👍

[donaldpipowitch]

I know React isn't build with TypeScript, but I think the new hooks feature illustrates my original use case quite nicely. Taken the question if hooks are useful or not aside, their correct usage relies on certain behavior (like ordering) which can't be covered by static typing alone. The React team created a linter rule which helps users to use hooks correctly. IMHO it would be really nice, if a lib like React could ship with these rules and every time I import the lib TypeScript would pick up these rules automatically without setting up additional tooling. (Given the lib is written in TypeScript. And if not... I guess a DefinitelyLinted project wouldn't be too far away to support non-TypeScript libs. :))

[RyanCavanaugh]

I don't see much left to do here that wasn't already done. LS plugins exist and side-by-side error providers in editors are well-supported.