Enabling JSLint/ESLint/TSLint in ReSharper and Rider
By default, JSLint/ESLint/TSLint rules are not included in ReSharper and Rider’s code analysis. We thought it sensible to make this an opt-in feature – which can be enabled from the settings.
There are a few things we can configure here:
- Enable integration of the tool.
- Optionally, we can specify the path to the
tslinttool. When not specified, ReSharper will automatically detect the tool if it is available from the
node_modulesfolder in one of our projects.
- Optionally, we can specify the path to our
.eslintrc.*for the other linters). ReSharper will find this file automatically, but it’s always possible to override and use a specific configuration file.
- If needed, additional command line arguments can be specified as well.
Note: a Node.js interpreter should be available on our system as well. ReSharper should automatically detect it when available in the
PATH environment variable. It’s possible to specify an interpreter explicitly in the settings under Tools | Node.js.
JSLint/ESLint/TSLint in action!
In our application, we’ve added a
tslint.json file with several rules. As an example, let’s ban the use of the uppercase
String type (and prefer lowercase
string instead). We prefer constants for variables that are never re-assigned. And in terms of quotes, we prefer
' instead of
". All rules that can be expressed with TSLint:
["String", "Avoid using the `String` type. Did you mean `string`?"]
After enabling JSLint/ESLint/TSLint in the settings, ReSharper (and Rider) will run the tool on our code, and displays results in the editor, in the same way built-in code inspections are displayed. Here are the example rules we configured above in action:
When JSLint/ESLint/TSLint provide a quick-fix, this will also be available after pressing Alt+Enter:
Another benefit of integrating JSLint/ESLint/TSLint static analysis results in ReSharper and Rider, is that when using solution-wide analysis (SWEA), linter results will be included: