Note: This extension has been deprecated in favor of the vscode-typescript-tslint-plugin. To learn about the differences between vscode-tslint and the new extension please refer to this document.
Integrates the tslint linter for the TypeScript language into VS Code.
Please refer to the tslint documentation for how to configure the linting rules.
The extension requires that the
typescript modules are installed either locally or globally. The extension will use the tslint module that is installed closest to the linted file. To install tslint and typescript globally you can run
npm install -g tslint typescript.
no-unused-variable rule doesn't report warnings any more?
Since tslint version 5 the rule no-unused-variable requires type information. Rules with type information are currently not supported by vscode-tslint, pls see [issue #70](https://github.com/Microsoft/vscode-tslint/issues/70#issuecomment-241041929). The recommended work around is to enable the TypeScript compiler options
noUnusedParameters in your
You can use the TypeScript setting
typescript.reportStyleChecksAsWarnings to define whether
noUnusedParameters are reported as warnings or errors. By default the setting is true.
How can I use tslint rules that require type information
The recommended way is to run tslint manually on your project from a task. To see the lint warnings in the Problems panel you can associate the task with a Problem matcher as described in the section below.
- First linting is very slow #287
When you have installed tslint globally using
npm install -g then you can get hit by a performance issue in npm. The command to determine the location of the global node modules can be very slow with version 5 of npm. This problem could not be reproduce with npm version 4.2. You can work around this issue by:
installing tslint locally for you project using
npm install tslint
define the location of the global node_modules folder using the
How can I distinguish errors warnings from tslint and TypeScript and how can I suppress them?
Error or warnings from TypeScript have the prefix
[ts], error or warnings from tslint have the prefix
[tslint]. You can suppress warnings as follows:
- typescript - use the
// @ts-ignore comment.
- tslint - use the
// tslint:rulename comment.
Open the tslint output log using the command
TSLint: Show Output. Verify that there is no error message in the shown log.
You can enable more tracing output by adding the setting "tslint.trace.server" with a value of "verbose" or "messages".
If this doesn't
help then please file an issue and include the trace output produced when running with the setting "tslint.trace.server" set to "verbose".
There were some reports that vscode-tslint could not be started due to missing files #342. Please file an issue when this happens and follow the work around described in the issue.
Notice this configuration settings allow you to configure the behaviour of the vscode-tslint extension. To configure rules and tslint options you should use the
tslint.enable - enable/disable tslint.
tslint.jsEnable - enable/disable tslint for .js files, default is
tslint.run - run the linter
onType, default is
tslint.rulesDirectory - an additional rules directory, for user-created rules.
tslint.configFile - the configuration file that tslint should use instead of the default
tslint.ignoreDefinitionFiles - control if TypeScript definition files should be ignored, default is
tslint.exclude - configure glob patterns of file paths to exclude from linting. The pattern is matched against the absolute path of the linted file.
tslint.validateWithDefaultConfig - validate a file for which no custom tslint configuration was found. The default is
tslint.nodePath - 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.
tslint.autoFixOnSave - turns auto fix on save on or off, or defines an array of rules (e.g. [
no-var-keyword]) to auto fix on save. Note: Auto-fixing is only done when manually saving a file. It is not performed when the file is automatically saved based on the
files.autoSave setting. Executing a manual save on an already-saved document will trigger auto-fixing.
tslint.alwaysShowStatus - always show the
TSLint status bar item and not only when there are errors. The default is
tslint.alwaysShowRuleFailuresAsWarnings - always show rule failures as warnings, ignoring the severity configuration in the
tslint.packageManager: use this package manager to locate the
typescript modules. Valid values are
"yarn". This setting is only consulted when the modules are installed globally.
The extension supports automatic fixing of warnings to the extent supported by tslint. For warnings which support an auto-fix, a light bulb is shown when the cursor is positioned inside the warning's range. You can apply the quick fix by either:
- clicking the light bulb appearing or by executing the
Quick Fix, when the mouse is over the erroneous code
- or using the command
Fix all auto-fixable problems.
When there are overlapping auto fixes a user will have to trigger
Fix all auto-fixable problems more than once.
ProblemPatterns and ProblemMatchers
The extension contributes a
tslint4 and a
ProblemMatcher and corresponding problem patterns. You can use these variables when defining a tslint task in your
task.json file. The
tslint5 problem matcher matches the rule severities introduced in version 5 of tslint.
The problem matcher is defined as follows:
The meaning of the different attributes is:
owner attribute is set to
tslint so that the warnings extracted by the problem matcher go into the same collection as the warnings produced by this extension. This will prevent showing duplicate warnings.
applyTo attribute is defined so that the problem matcher only runs on documents that are not open in an editor. An open document is already validated by the extension as the user types.
fileLocation is taken as an absolute path. This is correct for the output from
gulp. When tslint is launched on the command line directly or from a package.json script then the file location is reported relative and you need to overwrite the value of this attribute (see below).
severity defaults to
warning unless the rule is configured to report errors.
You can easily overwrite the value of these attributes. The following examples overwrites the
fileLocation attribute to use the problem matcher when tslint is run on the command line or from a package.json script:
See the next section for an example.
Using the extension with tasks running tslint
The extension lints an individual file only. If you want to lint your entire workspace or project and want to see
the warnings in the
Problems panel, then you can:
use gulp that or define a script inside the
package.json that runs tslint across your project.
define a VS Code task with a [problem matcher (https://code.visualstudio.com/docs/editor/tasks#_processing-task-output-with-problem-matchers) that extracts VS Code warnings from the tslint output.
For example, here is an excerpt from a package.json file that defines a script to run tslint:
"lint": "tslint tests/*.ts -t verbose"
Next, define a Task which runs the npm script with a problem matcher that extracts the tslint errors into warnings.
Finally, when you then run the
tslint task you will see the warnings produced by the npm script in the
Problems panel and you can navigate to the errors from there.
Here is the complete setup example setup.