This project is read-only.


TFS does not autocheck/compile js files if not checked out


If you project is added to Team Foundation Server and your ts and js files are checked in and you rebuild/run your project it errrors out because the ts file's js file is checked in and therefor cannot be edited. You have to have all your ts files checked out.

And if you edit your ts file and it is auto checked out, the ts file's js file is not also automatically checked out and there is no option to checkout the js file. You have to manually checkout the ts file for its js file to check out for edit.
Closed Jul 28, 2014 at 11: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:


jopamer wrote Oct 5, 2012 at 8:03 PM

Thanks for the report! Better TFS integration is something we're looking into, but for now have you tried the "local workspaces" feature in TFS11? That may mitigate the problems you're facing.

jreate wrote Dec 14, 2012 at 5:08 AM

What about using TFS Build. Typescript .ts files do not get generated into .js in the TFS build server, therefore causing your deployed app to have 404 errors on all the .js references.
It would be nice if it integrated seamlessly when using TFS build server.

dmcweeney wrote Dec 14, 2012 at 12:37 PM

Any ideas of timing for better VS/TFS integration. Local workspaces are not an option for us.

Another issue I notices is that if you right-click on the generated js file, there is no Source Control options to do a check out there.



rcollette wrote Jan 29, 2013 at 4:57 PM

I think there should be an option at least to treat .js files created by TypeScript the same way that aspx designer files are. They are created as a dependent file and included in source control automatically.

stanthomas wrote Mar 20, 2013 at 10:37 PM

The generated .js files should be regarded in the same way as .obj files and not added to source control. But I can see there's a problem in projects with mixed ts and js sources. Maybe rename all the .js files to .ts and exclude all .js from source control?

GaryB611 wrote May 29, 2013 at 9:47 PM

my project has app1.ts, app1.js, app2.ts and app2.js. If I check out app1.ts, app1.js is automatically checked out too, like an aspx designer. That seems fine. However if I build the project, tsc has a problem because app2.js is not writable. The build command is building ALL ts files. Must I check out all the ts (and automatically the associated js) files before building the project??

dmcweeney wrote May 30, 2013 at 9:33 AM

Hi Gary,

What I do now is delete the .js file from source control immediately after adding the .ts file - the .js file is like a build output now - works much better now for doing builds from the command line etc.

What would be really nice is if you could do conditional compilation and target debug and release builds to corresponding subfolders.

Hope this helps


GaryB611 wrote May 30, 2013 at 3:34 PM

my problem is with app2.js being checked-in when I want to work on app1.ts because the build command wants to build everything app1 and app2. i'll take this over to stackoverflow because on further reading of this site this board is for discussion of the specs. thanks.

GaryB611 wrote May 30, 2013 at 5:42 PM

Hey guys sorry to spam up this thread. I did notice that this work item was ranked "Low Impact". I am trying to sell TypeScript into my large organization because I love it so! I dreamed of hitting the ground running, in production, with release 1! I won't even be able to demo 0.8 in our solution like this.

Here's how my demo fail goes:


  1. Install the plugin
  2. Create a new "HTML Application with TypeScript" project (project A)
  3. Get an existing project (project B) from source control
  4. Copy project A's csproj tsc build stuff into project B's (I used notepad but that's another topic)
  5. Somehow get "TypeScript file" into the add context menu of project B (I forgot how I did this but that's still another topic)
  6. Add a new app1.ts file. Observe the associated app1.js. "Associated" understood as "like an aspx designer file"
  7. Check app1.ts into TFS. Observe the associated js is also checked in. Observe that the project is all snug and checked in in its entirety
  8. Build the project with the VS2012 menu
  9. tsc fails with "return code 1"
My peers and architects raise an eyebrow before I can mention the existence and status of this work item. If there's a better set of steps for a demo with this title I would love to hear them. Thanks for TypeScript!

rcollette wrote May 30, 2013 at 6:46 PM

I think I mentioned this in another thread somewhere but the problem with excluding the generated .js files from the project is that you then have no way to mark them as embedded resources if you are building something like a custom control. Designer generated code gets checked in just fine, no one complains about that generated code being included in source control so I don't see any reason why the generated .js code should not be checked in as well.

Another issue, imagine if two developers have different versions of TypeScript installed. One might build and deploy a generated .js file that is different than another developer. If you are not checking in these files, you won't even notice that there is a difference in the build (that I can think of). We can target a .NET version but there isn't an equivalent TypeScript target version (again that I am aware of) specified in the project.

manfredw wrote Jul 19, 2013 at 12:25 PM

this behaviour of the typescript compiler prevents the use in large projects with many developers.

It would be very helpfull if the dependent files only need to be checked out if the compiler output really changes.
At the moment it is required to check out all .ts and .js file to make minor changes in one file.
This is really a show stopper.

bnemetchek wrote Aug 20, 2013 at 6:54 PM

Facing the same problem with TFS, I found a more workable solution is to set turn off the read-only attribute of the .js and .map files in the project with a batch file. Then the compile of only the file you're working on will work fine without having to check out the others. The only side-effect of this is that when you perform a get-latest of the the project files, you either need to turn the read-only flag on again or you will see file conflicts in the conflict resolution page. I normally just select all conflicts and choose to overwrite local copy.

kubal5004 wrote Aug 23, 2013 at 8:31 AM

Please do this, because it is driving our whole team crazy!

jonturner wrote Aug 23, 2013 at 3:46 PM

The current approach to this issue starting with 0.9.1 is that we won't treat the .js as part of the project. Instead you can think of the JavaScript as the product of compilation, like an .exe or .dll. The focus for the project is on the TypeScript files used to generate the output.

You can still view these files using "Show All Files", but they will not be nested under the TypeScript files. This should let you more easily check in the source to build the JavaScript, without, as it was before, also checking in the JavaScript by default.

We have a blog post planned to cover these, and more, changes in a better detail, which we hope to publish soon.

rcollette wrote Aug 23, 2013 at 5:07 PM

@jonturner. It is unfortunate that this is the approach as I have outlined previously.
  1. You are not generating compiled code, you are generating source, much like designer generated code for a web form.
  2. The source needs to be included in the project when creating an embedded resource.
  3. If two developers happen to have different versions of TypeScript installed, the version of generated and deployed code is not tracked in source control. There is no way to detect or approve "changes" are happening.
You should at least provide the option to include the .js file in the project and in source control and treat it the same as a designer generated file, automatically checking out the file as needed. I would hate to see this be another one of those MS technologies that gets to good but dies on delivery (ex. linq to sql, etc.)

manfredw wrote Aug 27, 2013 at 9:37 AM

I was facing the same problem and finally the we found that it was possible if the generated javascript files are not under source control.

Javascript files may still be in the project in the solution explorer, but not in teamfoundation server. You can do this by manually deleting the files and adding the JS files to the project file manually:
<TypeScriptCompile Include="Scripts\Foo.ts" />
<Content Include="Scripts\Foo.js">
<Content Include="Scripts\">
Or remove the javascript files from source control in the team explorer or in the working folder using tfs power tools.

If you build the project the first time (with the javascript files missing) the files will be generated.

It is the same problem as if you are working with silverlight files from another project or using assemblies instead of project references.

i also had to add following manually to the project file:
<PropertyGroup Condition="'$(Configuration)' == 'Debug'">
<PropertyGroup Condition="'$(Configuration)' == 'Release'">
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.targets" />

When using amd modules use following compiler option: <TypeScriptModuleKind>AMD</TypeScriptModuleKind>

you can also use a power-shell build script - you may be free to do anything there.

ChrisTorng wrote Aug 28, 2013 at 6:15 AM

I wish to see the changing between versions of js, so I still wish to check in those js.
The changing maybe due to changing in ts, maybe just upgrade the TypeScript compiler.
And now, by reference to, it publish js, but it won't publish ts and map, that makes debugging online web server hard. I have tried to set ts file CopyToOutputDirectory PreserveNewest, but with no luck.

manfredw wrote Oct 3, 2013 at 10:02 AM

the Javascript files are the compiler output, therefore are written in every build.

To create .map files you can edit the typescript compiler options in the project file.
Then the file is generated.

If it is published or not has nothing to do with typescript or the compiler. You can edit the settings in your solution explorer. By default "copy to output directory" is not set - you may change to "copy if newer" or "always" then the files will be present after publishing.

If you want to track changes in the .js files you can do so, but the typescript compiler does not check out files. You can do it yourself with a power shell build script and tfs power tools.
-> check out all .js files
ts compile
(maybe compare)
-> check in

jonturner wrote Oct 24, 2013 at 5:44 PM


As manifredw pointed out, one solution here is to work with the JavaScript projects as part of your project but outside of source control. Not saying this doesn't have trade-offs, but it fits a little better with the TypeScript workflow. For example, if you also used a concatenation and minification step, if you checked this result into source control you'd still need a way to handle how to automatically check out this file. TypeScript tries to be just one part of this toolchain rather than the whole thing.

(PS: apologies it took so long to reply.)


Just to add a little more here. You can publish to a website and debug locally, by using "--sourceRoot" and "--mapRoot" you can control where the .map file and source files are looked for. These settings are fairly manual, and require you to also place the files in the correct places, but should give you something to work with.

rcollette wrote Oct 24, 2013 at 6:42 PM

I still consider these "solutions" to actually be work arounds to the problem. You say that this is just one tool in the chain. Lets look at Microsoft's own tool chain. ASP.NET bundling. This is done with deployed JS at runtime, not at compile/build time.

I still think the team is taking a "this is the way we want it to work" approach rather than meeting the needs of the customers, and its an approach the WCF team took in some circumstances as well. I once had a discussion with someone at MS about certain WCF behaviors that could only be "configured" through attributed code and the person completely dismissed, by way of some architecture rationalization, the fact that third party code, for which I did not have the source needed to be configured in a way that enabled it to run behind a load balancer. You can have all the architecture discussions you want but if it doesn't meet the needs of the customer it was done incorrectly.

"JS is code whether generated from a TypeScript compiler or not, we need to track changes to that code and we need to do so in a manner that doesn't make builds horrendously slow."

That requirement can be ignored but I guarantee that problems will ensue. It is not like this is a 20% outlier scenario. It is a rational need.

Why am I beating this concept to death... because TypeScript is actually GREAT. It makes me far more productive. I can't stand the fact that tooling decisions will get in the way of me being able to use it at a large scale.

Ounce wrote Nov 27, 2013 at 1:02 PM

You can also make TypeScript behave more like LESS. Note: As of version, you will lose AMD code generation features, e.g. export assignments.
  1. Make sure the build action of your TypeScript files are set to Content instead of TypeScriptCompile.
  2. Compile on save still works if enabled in Tools->Options->Text Editor->TypeScript->Project->General.
  3. Save your TypeScript files and add the new JavaScript files to your project.
    Unload your project and set your JavaScript file to be included as dependent upon the respective TypeScript files. Not required but, in the end, this is how your project tree should look to start with.
  4. While editing your project file, remove the project reference to Microsoft.TypeScript.targets and all TypeScript-related settings from your build configurations.
If TypeScript files aren't compiled on build, then JavaScript files don't need to be checked out, and TypeScript doesn't need to be installed on your build machine.

I wish they'd add full support for this behaviour and allow developers to configure whether to use AMD or CommonJS code generation in their projects.

Ounce wrote Feb 13, 2014 at 9:31 AM

I am sad to find that as of version 0.9.5, the no auto-checkout issue has got even worse. When TypeScript is configured for a project - which also happens if you add a new TypeScript file - there is not project option to disable comple on build, and if the JavaScript file is checked in, an emit error message appears and VS2013 crashes! Why can't we have JavaScript files check in under TypeScript files much like CSS files under LESS files? One soution is to set the build action to Content instead of TypeScriptCompile, and then you might as well remove all TypeScript-related configuration from the project file... But then the configuration keeps getting added back into the project file whenever I add a new TypeScript file to my project! Why can't I use my global project options for TypeScript as they are set in VS2013 without needing to keep removing project-level configuration?

Quango wrote Aug 29, 2014 at 9:39 AM

Quick update for anyone still interested: Visual Studio 2013 update 3 seems to have fixed this problem.

If you update a .ts file under TFS source control and save a change, both the .ts and .js files are checked out automatically. I still have to manually add the .js file to the project and nest it under the .ts file, but at least now you can compile a checked-in project (it will check out, compile and check in the .js file!)

I also use WebEssentials but I don't think that is the source of the behaviour.

rcollette wrote Aug 29, 2014 at 1:12 PM

@Quango - Yes but what happens when everything is checked in and you do a recompile? In VS 2012 the compile will fail because it cannot write the .js file (Which it shouldn't have to because nothing has changed).