TSLint in Visual Studio and CI builds

TSLint for TypeScript can provide lots of valuable information about your TypeScript code base. Surfacing that information to developers in the Visual Studio IDE can be accomplished in multiple ways. One way is through one of Mads Kristensen’s extensions, but it only surfaces warnings for currently open TypeScript files.

Another popular technique is to execute TSLint in a gulp or grunt task. But that leads to potential issues in a CI pipeline with requiring a full npm install step in the build definition, costing a lot of execution time (due to lack of caching in npm, which yarn might alleviate).

Fortunately there is another option that simplifies things, and it is Joshua Goldberg’s excellent TSLint.MSBuild NuGet package. This package includes a MSBuild .targets file which will utilize nodeJS (included in the package) to execute TSLint after compilation of TypeScript is complete, thus surfacing the TSLint warnings into the Visual Studio Error List window for the entire project during a build (and it also works in a CI build as well!).

Joshua’s github page has excellent documentation, but I’d like to reinforce a couple points that were initially tricky for us when we included this tool in our repertoire. First, TSLint is not included in the NuGet package (but the node executable is); you can either install a NuGet package to get TSLint, or it will fall back and detect a npm install’ed version of TSLint (which depends on TypeScript as well). The target will detect TSLint in your node_modules folder of your project if you do not specify where to find it or include the NuGet version of TSLint.

You’ll have to edit the .csproj file directly to provide settings for this package, and you will definitely want to have some “excludes” defined, and his example for excluding the typings folder is one we use, and it goes in an “ItemGroup” section like so:

The other important options go in a PropertyGroup:

You’ll need to specify the filename of your TSLint config file (typically tslint.json). If you have a large project with many TypeScript files, the length of the generated command line for tslint will exceed the maximum allowed length due to so many filenames being presented on the command line. In that case, you should create a tsconfig.json file (intended for the tsc compiler), in order to define which files to lint, using the files or include/exclude properties. The TSLintFileListDisabled property will indicate that the filenames should NOT be passed on the command line, but instead will be inferred from the project file. Other settings for tslint and the typescript compiler can be specified in that file, see their documentation for more info.

One final snippet that you may find valuable is if you also use a tool like NCrunch for continuous testing which creates its own copies of your code, as it does not make much sense to have NCrunch also run TSLint (since it would just eat the warnings and waste time). You can conditionally disable TSLint if the build is running “in an NCrunch build” with this condition:

Happy linting! Improving your TypeScript code base gets easier when including a tool like TSLint as a part of your continuous inspection pipeline.