Ensure TypeScripts projects are supported

[amitapl]

• Verify whether typescript projects are supported with recent changes
• Add test to make sure they stay that way
• Document support

Relates to #556

@Gissues:{"order":83.17307692307682,"status":"backlog"}

[smithkl42]

Something else that's important to note here is that the TS team is recommending that the build targets for TypeScript - i.e., the associated .js and .js.map files - shouldn't be a part of the project, and shouldn't get checked into source control. Right now, even if you follow the appropriate workarounds in issue #556, and your project gets deployed, if you don't have your .js and .js.map files as a part of your project and checked into source control, they won't get deployed. That obviously needs to change, and the .js, .js.map, and .min.js files produced by the TS compiler, need to be treated more-or-less the same way the .dll files are.

[davidebbo]

I think one concern at the time was that TS was evolving really fast and that the build target file was not 'stable' enough to hardcode machine level. This may not be an actual issue now.

[smithkl42]

I'm sure there will be more changes, but it does seem like TS is getting more stable these days. The 0.9.1 release was a major bust, but 0.9.1.1 seems to be very solid; and I don't foresee a ton of breaking changes in the build target file between now and 1.0.

That said, there are existing workarounds - they're just kind of a pain.

[ManfredLange]

When developing an ASP.NET MVC application I think it is not an uncommon scenario if people choose to add a TypeScript file where they used a JavaScript file in the past. Therefore supporting TypeScript out of the box would be a very valuable feature. Please consider for inclusion soon. The workarounds that require custom deploy scripts are complex and error prone. It would be great if JavaScript that is produced as output from TypeScript was treated like other intermediate files, e.g. assemblies generated from C#. The latter are included in the deployment of a web site.

[davidebbo]

So I haven't used TypeScript much since the early days. Kudu aside, does TypeScript support with msbuild projects work as you expect on your local machine? Specifically, if you do a deployment to a local folder (per these steps), does everything get deployed properly?

[ManfredLange]

I followed the steps as suggested and yes, the "intermediate" files that are a result of the TypeScript compile appear in the published site. David, this is the issue that Thiago forwarded to you mid of last week (8 Jan 2014). It works locally but it doesn't work in Azure Website. Therefore I left my comment here as suggested.

I'm now looking into installing the TypeScript compiler using npm and a custom deploy script. Not my preferred option but by the looks of it the best workaround available.

The other workaround that I had in place so far was versioning the JavaScript files (output of TypeScript compile) as well and add them to the project. This results in them being deployed. However, that causes for every TypeScript file to have their JavaScript visible in the solution explorer so makes it much harder for developers to work with the project. We would like to avoid having the "intermediate" files being added to the project and being versioned.

[davidebbo]

I don't recall that Thiago issue; do you have a link?

Anyway, it would be great if you could share a simple repo that does the publishing the right way locally and that doesn't work in Kudu. That would give us something to verify that it works once we come up with a fix. Thanks!

[ManfredLange]

David, a repository that you can use to reproduce and later test is available at https://bitbucket.org/ml_agileutilities/typescript-sample. It contains one single ASP.NET MVC project with one TypeScript file, UpdateFooter.ts. The code just prints a message into the footer of the site using a red font. Other than that this is a boilerplate ASP.NET MVC app created with VS2013. This compiles properly and can be deployed to a local IIS successfully. However, git deploy to an Azure Website fails with error MSB4019 "The imported project "D:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\TypeScript\Microsoft.TypeScript.Default.props" was not found." Workarounds appear to be available, e.g. using a custom deploy.cmd script. I have managed to get the custom deploy script to work as such but not yet the part that would allow me to remove the javascript files (TypeScript compile output) from version control. Eventually I will be able to make it work. It would be nice if building a website on Azure works the same as locally, including getting the TypeScript compiler to work via the msbuild build targets, which appear to be missing or are not available at the same location.
Some workarounds that I have been looking at: http://stackoverflow.com/questions/14883496/is-there-a-way-to-run-the-typescript-compiler-as-part-of-the-azure-git-deploy, including your answer. I'll continue to experiment down that path.

[davidebbo]

Seems your repo is in a bad state relating to NuGet packages. You have the packages folder committed, but it's missing all the DLLs in there (e.g. see here). Generally, it's best not to commit the packages folder at all. Clearly, that's not directly related to the TypeScript issue, but it does make the repo unusable as is for repro purpose.

[ManfredLange]

Thanks, will change that by removing the packages from the folder and enabling nuget package restore.

[davidebbo]

Actually, you shouldn't enable restore, as that's the old way of doing thing :) See Automatic Package Restore in Visual Studio and Command-Line Package Restore in http://docs.nuget.org/docs/reference/package-restore

[ManfredLange]

I removed both the package folder and the .nuget folder from the repository. Let me know if there is anything else you want me to do, so that the sample works as repro. Thanks for the hint regarding package restore.

[davidebbo]

Thanks this is very useful for testing the scenario end to end. We now understand what we need to do to make it work, though I don't have a clear ETA for it.

[ManfredLange]

I found a workaround that doesn't require a custom deploy script. The blog post is available at http://manfredlange.blogspot.co.nz/2014/01/aspnet-mvc-typescript-azure-website-and.html. The source code for the example project referred to in the blog post is available at https://bitbucket.org/ml_agileutilities/typescript-sample. There is a branch that reproduces the issue and there is a second branch that includes the workaround.

[davidebbo]

TypeScript should be working now. e.g. we use this test repo: https://github.com/KuduApps/MvcAppWithTypeScript

[davidebbo]

Note: if you get an error that looks like:

error MSB4019: The imported project "D:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\TypeScript\Microsoft.TypeScript.Default.props" was not found

The following change may be needed in your csproj:

<Import
  Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.Default.props"
  Condition="Exists('$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.Default.props')" />

[ThatRendle]

Any news on when TypeScript 1.0 will be installed on WAWS instances?

[mwtian-zz]

@markrendle It should be out in a week or two.

[smithkl42]

Any news on when TS 1.1 (CTP or otherwise) will be available for Kudu to run on WAWS instances?

[mwtian-zz]

Thanks for letting us know about the development! I think we can make it available by the end of next week.

[smithkl42]

@mtian - thanks! Looking forward to being able to use TS 1.1 in my builds and deploys.

[luisrudge]

Still not available.

D:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\TypeScript\Microsoft.TypeScript.targets(95,5): error : Your project file uses a different version of the TypeScript compiler and tools than is currently installed on this machine. No compiler was found at D:\Program Files (x86)\Microsoft SDKs\TypeScript\1.1\tsc.exe. You may be able to fix this problem by changing the <TypeScriptToolsVersion> element in your project file.

[mwtian-zz]

@luisrudge It is bundled with some other changes which got delayed a little bit. It should be up next week or earlier!

[luisrudge]

@mtian great! Thanks!

[davidebbo]

@luisrudge could you give it a try in the Brazil South region? It's supposed to have the change already, though most other regions don't (they will in coming days). And it's close to you :)

[luisrudge]

@davidebbo It's already working on west europe. My build was breaking two days ago, but it ran just fine about 8 hours ago! Thanks!

[davidebbo]

Great! It's still deploying, so it will not work globally for everyone until a while later.

[smithkl42]

@davidebbo - And of course, now TS 1.3 is out. (No rest for the wicked.) I haven't tried it with Azure git deploy yet - can I presume it'll be out in another week or two?

[davidebbo]

@smithkl42 yep, we need to do this! It may take a few weeks though, so bear with us :)

[smithkl42]

@davidebbo - What's the best way to check to see whether 1.3 is supported yet? Will you announce it here? Or is there a blog I should be checking? Or do I just need to test it periodically? Or...? (TIA)

[davidebbo]

Sorry, it's not supported yet. Yes, we'll respond on this thread when it is.

[smithkl42]

Thanks! Looking forward to having it available.

[kamranayub]

Chiming in for support! Thanks guys.

[smithkl42]

@davidebbo - I haven't seen anything on this thread, so I presume that it's not yet supported, but I just wanted to check and see what the status was. In looking at the TS commits, it looks like 1.4 is about ready to make its appearance, so it'd be handy not to be two releases behind :-).

And, I suppose, it also raises the question: is there a way to remove this dependency altogether? It'd be handy not to be any releases behind, i.e., not have to wait for an Azure rollout before the latest TS tools (or other tools) are available. Is there a way to access this stuff without depending on Azure to provide it for us?

[davidebbo]

Not depending on Azure would likely imply some approach that gets all the relevant tools inside your own site files. Remains to be seen if the tools support this type of xcopy deployment, or whether they have all kind of registry ties that would make this unworkable.

Thanks for the heads up on 1.4. This probably won't happen till January, but we'll get there.

Is 1.4 side by side with 1.3, such that we need both, or does having 1.4 make it moot to have 1.3?

[smithkl42]

Unfortunately, MS hasn't released the Visual Studio integration piece as open-source, so you don't get to preview that before the actual release. (Not sure why.) So I don't know precisely how the 1.4 integration will work. But see this answer here for more details about how it's worked so far:

http://stackoverflow.com/a/26915217/68231

Basically, it sounds like you ought to be just fine with just 1.4 installed - it will presumably support all the language features of 1.0, 1.1 and 1.3, and so code targeting those versions will compile correctly with 1.4.

[davidebbo]

Thanks, we'll try to discuss with internal contacts to get a better sense about the 1.4 release.

[smithkl42]

@davidebbo - Sorry to bug you again :-). 1.4 is out now - any update on when that'll make its way onto Azure websites?

[davidebbo]

Yes, we're trying to get 1.4 on there soon. It may only be in some regions to begin with. Are you set up to verify that it works well, once it's ready on our side?

[smithkl42]

Yup, easily. Would only take about 5 minutes.

[davidebbo]

Ok, can you create a test site in South Brazil now and give it a try? Ironically, it has 1.4 but not 1.3 (which will come later). Don't ask...

[luisrudge]

Awesome! That's why I love Brazil! :)

[davidebbo]

Yes, for some reason, we have a 'tradition' of deploying Brazil first! But the rest shouldn't be far behind. :)

[smithkl42]

@davidebbo - I was able to successfully deploy to South Brazil with 1.4. Looking forward to it landing in US West :-).

[davidebbo]

It's everywhere now.

[luisrudge]

That was fast. Thanks @davidebbo!

[smithkl42]

Awesome! Thanks!

[davidebbo]

Were you able to try a test scenario? It works for us, but it would be good confirmation as we didn't try anything too fancy.

[smithkl42]

@davidebbo - Nothing too fancy, but I was able to get my web project to compile and deploy with the TSTools set to 1.4 - which was the scenario that had failed yesterday.

[davidebbo]

Awesome, thanks for confirming!

[sjkp]

What about visual studio node js projects? It doesn't compile typescript in those :(

[ahmelsayed]

@sjkp Do you have a sample repo for that somewhere I can take a look at?

[sjkp]

https://github.com/sjkp/SJKP.CvrRegnskabsData this is the one i tried with. Build in VS2015.

[ahmelsayed]

I see. We currently don't support .njsproj projects in Kudu. Can you please open another issue for tracking this?