Chutzpah 3.2 – A smarter approach to compilation

Chutzpah 3.2 introduces a new and improved method for supporting languages which compile to JavaScript. This version puts the power in your hands to tell Chutzpah how to compile and lets Chutzpah get out of your way. As always  you can get the new bits from CodePlex, NuGet or go to the Visual Studio Gallery to get the updated Visual Studio Context Menu Extension  and Unit Test Explorer adapter.

Changes

Smarter Compile

When I first added support for compiled languages (like TypeScript and CoffeeScript) to Chutzpah I was trying to make it super simple to use. I embedded both CoffeeScript and TypeScript inside Chutzpah and executed them at test time by hosting the IE script engine to produce the needed .js files. This approached worked ok but led to a few major issues/pain points:

  1. Versioning: Chutzpah needed to ship with a specific version of TypeScript since the api’s needed to run the compilation kept changing. This led to a bad issue of a user wanting to use version X but Chutzpah only supporting Y.
  2. Performance: Chutzpah’s compile was slow and not smart about when it needed to run.
  3. Memory: The hosting of the IE script engine led to a native memory leak when you run your tests using VS Test Explorer.
  4. Philosophical:  Chutzpah should not be responsible for determining how to compile your source code. It was a mistake to mix this concept into Chutzpah. It should have been decoupled from the start. Live and learn ;)

Given those pain points I still like the idea that you can point Chutzpah at your source files and you should still be able to get test results that point back to the test files. This led to the new chutzpah.json compile setting. This setting lets you describe in the Chutzpah.json file how to execute a command which can compile your source files to .js files. You tell Chutzpah what to execute and some information about what your executable does (like where to find the generated .js files). Then after running the executable Chutzpah can associate each source file with each output file to still give the nice behavior of mapping tests back to their original files.

You should ideally configure this compile setting to use the same mechanism you have for compiling the code in your project. This will give you a nice performance gain when running Chutzpah since it will re-use the .js files you have already built. This becomes really powerful when you are taking advantage of IDE integration features that TypeScript and CoffeeScript plugins have that provide a compile on save experience. If configured correctly Chutzpah will be able to use the the output of that feature and never need to actually invoke the compile step. This results in a *very* fast test running experience.

When Chutzpah sees that you have the compile configuration set it will not use the legacy integrated compilation.

Below are the options for the Compile setting:

Field Default Description
Extensions [] The extensions of the files which are getting compiled (e.g. .ts).
ExtensionsWithNoOutput [] The extensions of files which take part in compile but have no build output. This is used for cases like TypeScript declaration files which share a .ts extension. They have .d.ts extension and are part of compilation but have no output. You must tell Chutzpah about these if you want the SkipIfUnchanged setting to work. Otherwise Chutzpah will think these are missing output.
SourceDirectory Chutzpah.json directory The root directory where all the sources the command compiles are below. This lets Chutzpah know where in the out dir it should find each reference file
OutDirectory Chutzpah.json directory The directory where the compiled files are output to
WorkingDirectory Chutzpah.json directory This is the working directory of the process which executes the command.
Executable null The path to an executable which Chutzpah executes to perform the batch compilation. Chutzpah will try to resolve the path relative to the settings directory. But if can’t find the file there you must give it a full path.
Arguments null The arguments to pass to the command
Timeout 30000 (5 minutes) How long to wait for compile to finish in milliseconds?
SkipIfUnchanged true Skips the execution if all files Chutzpah knows about are older than all of the output files. This is defaulted to true but if you hit issues since it is possible Chutzpah might not know about all the files your compilation is using then you can turn this off. Ideally you should tell Chutzpah about these files using the references and tests settings since this setting helps Chutzpah not need to even invoke the executable if it figures out it’s not needed.
Mode Executable Determines how this compile setting is used. By default it is in Executable mode where it will require you provide an executable which Chutzpah will run if it sees it finds missing .js for input file. If you set this to External then Chutzpah will ignore the Executable, Arguments settings and assume you have some external process which is compiling. In this case Chutzpah will use the SourceDirectory and OutDirectory options to try to find your .js files for the input files. If it can’t find them it will trace an error but still attempt to proceed.

 

For the Executable, Arguments and OutDirectory fields Chutzpah lets you put in variables which get expanded at execution time. These can be system environment variables like %comspec% as well as the set of Chutzpah provided variables below:

%chutzpahsettingsdir% The directory the chutzpah.json is in
%clrdir% The directory to the folder where the CLR is. This folder contains programs like msbuild.exe
%msbuildexe% The path to msbuild.exe
%powershellexe% That path to powershell.exe
%cmdexe% An alias for %comspec% which is the path to cmd.exe.

 

Integration with compilation tooling

Many users of TypeScript and CoffeeScript use IDE tooling which will already provide compilation of those files to JavaScript. In that case you should Compile Mode setting to External. This tells Chutzpah to assume that some external force is doing the compilation and that Chutzpah can just count on the JavaScript file to exist where you said they would be.

Examples

Enough talk! As part of this release I have included several examples which show different combinations of these settings. Below I will highlight three examples. One runs your compilation code using a .bat file, one uses a .ps1 file and the last runs an MSBuild project file. For each of these samples I will cover some interesting parts but for a complete picture please browse the full code of the samples.

All of the samples below assume you have tsc.exe in your system path.

Using a .bat file

This sample demonstrates compiling TypeScript files in place using a .bat filed called compile.bat.

chutzpah.json

{
 "Compile": {
   "Extensions": [".ts"],
   "ExtensionsWithNoOutput": [".d.ts"],
   "Executable": "compile.bat"
  },
 "References": [
   {"Include": "*/src/*.ts", "Exclude": "*/src/*.d.ts" }
 ],
 "Tests": [
   { "Include": "*/test/*.ts", "Exclude": "*/test/*.d.ts" }
 ]
}

 

compile.bat

@echo off
tsc src/code.ts test/test.ts --sourcemap

 

A couple interesting things about this example:

  1. It doesn’t set the outdirectory since the compile.bat command is compiling them in place.
  2. It gives a relative path for compile.bat since it is in the same directory as the chutzpah.json file
  3. It provides .d.ts as the ExtensionsWithNoOutput since although .d.ts are part of the compilation process they produce no output. This helps Chutzpah be smart about when it needs to run the compile executable.

 

Using a .ps1 file

This sample demonstrates compiling TypeScript files to a out directory using a PowerShell file.

chutzpah.json

{
 "Compile": {
   "Extensions": [".ts"],
   "ExtensionsWithNoOutput": [".d.ts"],
   "OutDirectory": "out",
   "Executable": "%powershellexe%",
   "Arguments": "-NoProfile %chutzpahsettingsdir%\\compile.ps1"
  },
 "References": [
   {"Include": "*/src/*.ts", "Exclude": "*/src/*.d.ts" }
 ],
 "Tests": [
   { "Include": "*/test/*.ts", "Exclude": "*/test/*.d.ts" }
 ]
}

 

compile.ps1

tsc src/code.ts test/test.ts --sourcemap --declaration --outDir out

A couple interesting things about this example:

  1. It sets the outdirectory in the chutzpah.json to match the outDir setting in the call to tsc.exe in compile.ps1. This tells Chutzpah where to find the .js files.
  2. It uses the %powershellexe% variable that Chutzpah provides to get the full path to powershell.exe in the executable field.
  3. It uses the %chutzpahsettingsdir% variable in the arguments field to build the full path to the compile.ps1.

 

Using an MSBuild project file

This sample demonstrates compiling TypeScript files to an out directory by executing a target in an MSBuild project file.

chutzpah.json

{
 "Compile": {
   "Extensions": [".ts"],
   "ExtensionsWithNoOutput": [".d.ts"],
   "Executable": "%msbuildexe%",
   "Arguments": "/t:CompileTS ",
   "OutDirectory": "out"
  },
 "References": [
   {"Include": "*/src/*.ts", "Exclude": "*/src/*.d.ts" }
 ],
 "Tests": [
   { "Include": "*/test/*.ts", "Exclude": "*/test/*.d.ts" }
 ]
}

 

compile.proj

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="12.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

 <PropertyGroup>
   <TscExe>tsc</TscExe>
 </PropertyGroup>

 <Target Name="CompileTS">
   <Exec Command="$(TscExe) src/code.ts test/test.ts --declaration --sourcemap --outdir out" />
 </Target>

</Project>

 

A couple interesting things about this example:

  1. The %msbuildexe% variable that Chutzpah provides is used in the executable field to get the full path to msbuild.exe.
  2. The arguments field calls the compile.proj using a specific target (CompileTS). You may notice this command doesn’t mention the project file compile.proj. In this sample it is assuming that is the only project file. If you wanted to be explicit you could change the arguments to: compile.proj /t:CompileTS

 

Future of the legacy TypeScript and CoffeScript integration

With the addition of the compile configuration setting I am deprecating the legacy (that is what I am calling it) existing integrated compilation functionality. For this release the legacy code is still there but it will no longer receive updates (besides upgrading TypeScript to 1.0 when it is released). In a future release I may REMOVE the legacy compilation support so please start the process of upgrading to the new compile setting.

 

Custom test function pattern

When Chutzpah reports test results it also tells you what line they are on. The way this is accomplished is by having a regex for each testing framework which describes where to find the names of your tests. For example for QUnit Chutzpah uses the following:

((?<!\.)\b(?:QUnit\.)?(test|asyncTest)[\t ]*\([\t ]*["'](?<TestName>.*)["'])

This works pretty well but if you use a library which provides a different syntax for specifying tests then this will fail. This results in all tests having no line number information. To fix this problem Chutzpah now offers a TestPattern setting in the chutzpah.json file. This lets you specify your own regex for Chutzpah to use. The requirement for this regex is that it needs to capture the name of the test in a capture group called TestName. For example lets say this is how your test file looks:

function TestClass() {

}

TestClass.prototype.test = function(name, callback) {
    QUnit.test(name, callback);
};

TestClass.prototype.testCase = function (name, callback) {
    QUnit.test(name, callback);
};

TestClass.prototype.registerTests = function(callback) {
    callback.call(this);
};

var testClass = new TestClass();

testClass.registerTests(function() {
    this.test("Pattern 1", function() {
        ok(true, "this test is fine");
    });

    this.testCase("Pattern 2", function () {
        ok(true, "this test is fine");
    });

});

 

Then you can use the following chutzpah.json to get correct line number information.

{
    "Framework": "qunit",
    "TestPattern": "this\\.(testCase|test)\\([\"'](?<TestName>.*)[\"']"
}

 

Require.js BaseUrl support

One of the issues that users reported after the addition of the improved Require.js support in the 3.0 release was that it doesn’t work correctly when you set a custom BaseUrl in the Require.js config or if you set a custom test harness location in the chutzpah.json file.  With this release Chutzpah contains a setting in the chutzpah.json file called AMDBasePath. This setting is a path relative to the settings file directory which should point to the same folder as your require.js baseurl. In addition, Chutzpah will also now correctly work when you use its AMD mode while setting a custom TestHarnessDirectory. To demonstrate the use of these changes I created three new samples.

CustomBaseUrl Sample – This sample demonstrates using Require.js with a baseurl setting along with the Chutzpah AMDBasePath setting.

CustomHarnessLocation Sample – This sample demonstrates placing your tests in a separate folder than your source but placing the generated HTML file at the root of your source.

CustomBaseUrlAndCustomHarnessLocation Sample – This sample shows a combination of both samples above.