Closed brettjacobson closed 7 years ago
Have you tried specifying TSLintCli
manually?
(I figured out the solution to the problem while writing the issue, but thought I'd create it and document the fix and close it for future reference)
The solution winds up being to disable TSLint during an "NCrunch build". This fixes the problem, and is also a good optimization to make just in general since even if we used the TSLint NuGet package (which NCrunch was happy with finding), its unnecessary to have NCrunch execute TSLint since its output goes nowhere :)
Added this conditional to our .csproj file to disable TSLint during an NCrunch build:
<PropertyGroup Condition=" '$(NCrunch)' == '1' ">
<!-- Disable TSLint during during NCrunch builds -->
<TSLintDisabled>True</TSLintDisabled>
</PropertyGroup>
:+1: Good solution, thanks!
FYI Yes we were specifying TSLint manually. The problem was that NCrunch redefines the $(ProjectDir) to be ITS sandbox, thus the node_modules folder wasn't in that path.
An interesting conundrum has occurred with our use of TSLint.MSBuild in our solutions. We use NCrunch for continuous testing of the C# code. NCrunch makes its own copy of the the build outputs and runs its tests in its own sandbox. Unfortunately, there is no way for NCrunch to keep NCrunch working if we specify this:
<TSLintCli>$(ProjectDir)node_modules/tslint/bin/tslint</TSLintCli>
Because NCrunch doesn't know it needs to copy tslint and its dependencies from node_modules into its sandbox, when NCrunch tries to run our C# tests, it hits a failure when the TSLint part of the targets is engaged. While MSBuild will continue running if it cannot find TSLintCli, NCrunch considers that error as catastrophic and stops its building (and hence, won't run the unit tests).