Gaps between tslint-language-service and vscode-tslint

[egamma]

• [ ] Show the user tslint warnings like 'rule not found'. blocked - currently shown in the server log only, which is intended for plugin authors but not users, see Microsoft/TypeScript#15913
• [ ] The no-unused-variable-rule is disabled by default blocked - the rule has side effects and triggers an assertion failure palantir/tslint#2649. There is a fix for the side effect, that will be available in a next version. Even with the fix the rule requires to re-analyze a file for linting and it is too expensive to enable.
• [ ] Auto fix on save blocked - the TypeScript language server has no notion of a pre save hook Microsoft/TypeScript#15917
• [ ] Automatically revalidate open files when the tslint.json configuration file changes. blocked - requires an API to trigger a revalidation of the open files Microsoft/TypeScript#15914
• [ ] Revalidate open files when the plugin settings inside the tsconfig.json changes. blocked - Microsoft/TypeScript#15915

Settings

• [ ] tslint.autoFixOnSave - fix auto fixable warnings when a file is saved. blocked see above
• [ ] tslint.run - run the linter onSave or onType, default is onType. blocked - typescript always creates diagnostics as the user types

Commands contributed by vscode-tslint

from Microsoft/vscode-ts-tslint#1:

• [ ] tslint.fixAllProblems - which also enables to define a key binding, requires to send a event to a plugin.
• [ ] tslint.createConfig - should be created using tslint --init
• [ ] tslint.showOutputChannel - depends on TS support for channel specific logging from a plugin see above

Custom quick fixes

vscode-tslint provides some custom quick fixes. Rather than providing quick fixes the better approach is to make PRs against the tslint rules.

• [x] quotemark - quick fix has been added in tslint 5
• [ ] triple-equals - no quick fix provided by tslint
• [ ] comment-format - no quick fix provided by tslint
• [ ] whitespace - no quick fix provided by tslint

Should be provided by tslint editor extension

• Intellisense/validation for language service plugins contributions in the tsconfig.json
• tslint status indicator the vscode typescript status indicator should show status/provide access to the status of extensions
• tslint.json schema validation
• support to create a default tslint.json

[angelozerr]

I work on a PR that addresses several of the above issues.

Very cool!

Quick fix for fixing all auto fixable rule failures Quick fix for fixing all rule failures for a particular rule

I think this feature should be supported by tsserver, no? But for the moment we could implement it.

Auto fix on save

I tell me more and more if getSemanticDiagnostics should have a context parameter. The context parameter is filled by the editor client and in our case we could ignore error or not. In Eclipse, I would like to have this parameter too to ignore compute of tslint fix when there is compile on save which is executed (in this case I don't need to compute fix for ts files which depends of the ts file which is saved).

I see several values for this context:

• onType
• onSave
• onCompile

Those values could be filled with a tsserver request when semantic command is called.

Revalidate open files when the tslint.json configuration file changes.

Could you create an issue at TypeScript please?

Intellisense for language service plugins

What do you mean?

support to create a default tslint.json

In typescript.java I provide a wizard which generates tslint.json with tslint --init

custom path to node modules directory, used to load tslint from a different location than the default of the current workspace or the global node modules directory.

It seems that TypeScript 2.4 will provide "global" plugins, perhaps it will fix this issue?

[egamma]

Quick fix for fixing all auto fixable rule failures Quick fix for fixing all rule failures for a particular rule

I think this feature should be supported by tsserver, no? But for the moment we could implement it.

Fair question, auto fixing has become popular for linters, but less so for general semantic language errors. So I suggest that we implement it first.

Auto fix on save

I tell me more and more if getSemanticDiagnostics should have a context parameter.

The more interesting issue is related to applying the code fixes, the changes must be applied before the save operation so that a document is not saved twice. This needs a new hook like aboutToSave that enables to apply changes.

Intellisense for language service plugins

What do you mean?

VS Code provides Intellisense when editing a tsconfig.son, see below. You want to have the same comfort when a plugin provides settings that you want to configure.

support to create a default tslint.json

In typescript.java I provide a wizard which generates tslint.json with tslint --init

This makes sense, vscode-tslint does something similar.

It seems that TypeScript 2.4 will provide "global" plugins, perhaps it will fix this issue?

This allows to configure a plugin globally, not clear to me yet, how global plugins support module dependencies of a plugin. Do you have a pointer with the latest on this?

[angelozerr]

So I suggest that we implement it first.

Ok!

This needs a new hook like aboutToSave that enables to apply changes.

Is it an issue for TypeScript or VSCode?

You want to have the same comfort when a plugin provides settings that you want to configure.

Thanks for the clarification. I think tslint-language-service should provide that (when getExtranlFiles will be implemented), no?

Do you have a pointer with the latest on this?

The only info that I have about global plugin is https://github.com/angular/vscode-ng-language-service/issues/43#issuecomment-299659872

[egamma]

This needs a new hook like aboutToSave that enables to apply changes.

Is it an issue for TypeScript or VSCode?

The typescript language server needs to provide a hook for aboutToSave to plugins. It also needs to provide a way for a tool like VS Code or Eclipse to inform that TypeScript server that an about to save is about to happen.

You want to have the same comfort when a plugin provides settings that you want to configure.

Thanks for the clarification. I think tslint-language-service should provide that (when getExtranlFiles will be implemented), no?

This would be possible, but the tsconfig.json file is a JSON file for which there is a JSON language service that can provide validation based on JSON schemas (and there is a schema for tsconfig.json). I would not want to duplicate this and compete with the JSON language service inside the tslint-language-service. What I suggest is that a plugin can provide a JSON schema fragment for its plugin attributes and the JSON language service can consume it and use it for validation (BTW, the VS Code JSON language server can also be used from Eclipse).

[egamma]

Regarding global plugins

This is already supported you can pass the TS server as set of plugin locations (directories) on the command line and the TS server will load plugins from these locations. This is used in VS Code to support loading a TS language server from a VS Code extension. This is what I'm doing in the preview of the 'tslint' plugin extension https://marketplace.visualstudio.com/items?itemName=eg2.ts-tslint

[probert94]

The no-unused-variable-rule is disabled by default
As a workaround you can use noUnusedParameters in tsconfig.json.
This however has a drawback with Angular AOT build: angular/angular#17131

[jrylan]

One other strange gap that I felt is important to note for this discussion is that VS Code currently only calls out to getFormattingEditsForRange in the TS Language Service, and never attempts to call getFormattingEditsForDocument.

[chemzqm]

Looks like no-unused-variable-rule is always disabled in tslint-language-service, any way I could make use of that? I don't like set allowUnusedVariable in tsconfig.json, since it doesn't allow me skip some variables.

[DimitryDushkin]

Hey! Is auto-fix available now?