<p dir="auto"><strong>TypeScript Version:</strong></p>
<p dir="auto">1.8.2</p>
<p dir="auto"><strong>Problem</strong></p>
<p dir="auto">I've found that somewhere between typescript 1.6.2 and 1.8.2, it started printing relative file names in error messages instead of absolute file names. This makes it harder for us to find the right (generated) input file, since we have to know what the paths are relative to. Was this change on purpose, or accidental? It's not listed in the change log.</p>
<p dir="auto">TypeScript Version: 1.8.5<br>
Visual Studio 2013 Version: 12.0.40629.00 Update 5</p>
<p dir="auto"><strong>Code</strong><br>
The code is available via a codeproject article, called "First Angular2 App with TypeScript and Visual Studio 2013." I downloaded the code, unblocked it, opened it in VS2013 and ran it.<br>
<a href="http://www.codeproject.com/Articles/1060262/First-Angular-App-with-TypeScript-and-Visual-Studi" rel="nofollow">http://www.codeproject.com/Articles/1060262/First-Angular-App-with-TypeScript-and-Visual-Studi</a></p>
<p dir="auto"><strong>Expected behavior:</strong><br>
When the application is Cleaned in Visual Studio 2013, and then rebuilt, it should regenerate javascript from typescript and then run if there are no errors. The problem is that there are errors that were probably not there in a prior version of TypeScript.</p>
<p dir="auto"><strong>Actual behavior:</strong><br>
The first time the application builds, it gets me to upgrade TypeScript to 1.8.5. The first time it runs, the application works successfully, I believe because the custom tool does not need to run as there have been no changes to the typescript file.</p>
<p dir="auto">Changing the typescript file will cause typescript to return "Build: Experimental support for decorators is a feature that is subject to change in a future release. Set the 'experimentalDecorators' option to remove this warning."</p>
<p dir="auto">This is in spite of having the TypeScriptExperimentalDecorators option set to true in the csproj file.</p>
<p dir="auto">But there is no need to even change the typescript file. Simply cleaning the code appears to cause the failure.</p>
<p dir="auto">The (poor) workaround is to tick the box to allow the code to be generated even if there's an error. Obviously this is bad especially if there are real errors needing to be corrected.</p>
<p dir="auto">Based on the number of demonstration apps out there I believe this option was working at some stage but is not working presently.</p>