13

Closed

TypeScript build target, Build Servers and support for multiple TypeScript versions

description

I have been working on an ambicious ASP.NET Single Page App project using TypeScript since the early 0.8.x versions of TypeScript, and we are getting close to release.

To ensure that our TypeScript codebase compile when building the web project with MSBuild, we have manually edited the Web project csproj file to import the Microsoft.TypeScript.targets build target (%ProgramFiles(x86)%\MSBuild\Microsoft\VisualStudio\v11.0\TypeScript\Microsoft.TypeScript.targets) and configured the build target settings in the project file appropriately to set the correct compiler flags (--sourcemap --target ES5 --module AMD [...]), and ensured that all our TypeScript files has the "TypeScriptCompile" property.

When migrating to new releases of TypeScript, we always check whether Microsoft.TypeScript.targets has changes, and update our csproj file accordingly whenever there are changes.

Our first challenge was making the build work on the build server.
To ensure that Web projects using Microsoft.TypeScript.targets will build successfully on a build server, you have two options:
  1. Install TypeScript on the build server
  2. Copy the required files for Microsoft.TypeScript.targets to a different source-controlled folder (in Git repository in our case) and change the path references in the csproj file to this folder.
Option 1 cons:
  • This requires that you have admin privileges on the build server and have permission to install software.
  • Only one version of TypeScript can be installed on the build server since the TypeScript installer cannot install multiple versions of TypeScript (.targets+compiler) side-by-side.
Option 2 cons:
  • You also need to copy the TypeScript compiler files (normally located under %ProgramFiles(x86)%\Microsoft SDKs\TypeScript) to a source controlled folder, and update the paths to the Compiler in the Microsoft.TypeScript.targets file.
  • When upgrading to newer versions of TypeScript, we need to manually ensure that the source controlled copy of Microsoft.Build.targets + required files and the TypeScript Compiler files are updated.
We opted for option 2, since we cannot install software on the build server.
We are actually building the project on Windows Azure, using a Windows Azure Web Site with continous deployment from our Git Repository.

This has all been working fine up till the 0.9.1 release of TypeScript.
With Version 0.9.1, the .targets file changed, but we have aligned with these changes in our source controlled copies of required TypeScript .targets and compiler files, and TypeScripts are compiling just fine when building locally from Visual Studio on our developer workstations.

But when building the Project on Windows Azure it does not work: The build fails and reports that it was failing on line 54732 in tsc.js, the ActiveX("Scripting.FileSystemObject") being unknown;
This was not a problem in 0.9.0.1 and earlier versions.

I am therefore begging for some help about how to solve this.
Currently we have entirely commented out the TypeScript.targets part in the Project file, and we rather use grunt/nodejs triggered as a post-build event to compile our TypeScript code.
But without the TypeScript.targets, we don't get Compile-On-Save inside Visual Studio.
We are currently getting Compile-On-Save using the Visual Studio Web Essentials plugin, but the latest Version of this plugin cannot compile with the correct compiler arguments, and the plugin is about to retire the whole TypeScript support. I feel we are getting pushed further and further into a corner on these matters.

I have to mention that I think the documentation published about TypeScript from the TypeScript team has generally been minimal, and I specifically find it hard to find any good information around:
  • Working with TypeScript in Visual Studio projects
  • Compile-On-Save in Visual Studio
  • Using Microsoft.TypeScript.targets in the project file.
  • Building your solution on a build server.
I think TypeScript is awesome, and I hope its popularity will not be diminished because of lacking documentation and difficulties like the ones I am experiencing. I think all the great work that has been put into the TypeScript design and compiler implementation deserves that someone writes and publishes some information about the practical sides of working with TypeScript from a development project lifecycle perscpective.

Suggestions:
  • It would probably be a good idea to make it possible to install multiple versions of TypeScript .targets + compiler side-by-side. I would also bet that the VM images for Azure Web Site servers would be updated with multiple versions installed so that the build process for projects with TypeScript files would run seamlessly regardless of version. It would also be possible to work on different projects with TypeScript code of different versions on the same machine.
Closed Jul 28, 2014 at 10:18 PM by jonturner
As part of our move to GitHub, we're closing our CodePlex suggestions and asking that people move them to the GitHub issue tracker for further discussion. Some feature requests may already be active on GitHub, so please make sure to look for an existing issue before filing a new one.

You can find our GitHub issue tracker here:
https://github.com/microsoft/typeScript/issues

comments

paulb wrote Aug 16, 2013 at 7:59 PM

thanks for the suggestion, assigned to Jon who handles our suggestions.

The problem you're seeing:

"it was failing on line 54732 in tsc.js, the ActiveX("Scripting.FileSystemObject") being unknown;" is probably due to an incompatible version of tschost.dll with the OS on your build server, reverting that to a previous version should solve this.

josundt wrote Aug 29, 2013 at 8:51 PM

Thanks for the tip about tschost.dll
I reverted to an earlier version which really saved my day!

Still hoping for some evaluation of my other thoughts in the report...

smithkl42 wrote Aug 30, 2013 at 9:22 PM

Agreed that TS needs to have a better story with regard to build servers. This may not be entirely TypeScript's fault, but it doesn't seem to play well with many CI servers as of yet. For instance, if you want to use the (very handy) git-deploy on Azure, you have to go through all sorts of unpleasant workarounds (https://github.com/projectkudu/kudu/issues/556), and even after you do all those, you still need to check your .js and .js.map files into source control. It would be great if the TS team could work with some of these CI servers to ensure that TS has a solid CI story.