TypeScript: TS2304 Errors appear for excluded files in Visual Studio 2017

Awaiting solution to this issue.

MSFT putting any more effort into VSCode other than the initial push and governance seems like a broken business model to me seeing as the program is freely given away and VS collects license money.

On the same token, MSFT putting any features into VSCode that arent put into VS first. or prioritizing non-critical-path feature work for VSCode before bug fixes for VS is flatly the wrong thing to be doing in regards to their customers that paid for a license for the world’s premiere IDE.

@simeyla - I’m not upset with you suggesting it, since you are also a victim of their unfortunate choices. I’ve had MSFT staff make suggestions to “just use VS code” instead of fixing a bug in VS before and its carries all the negative emotions that accompany getting ripped off for an amount in the high 4/low 5 digit range (like buying a car that is full of problems and the seller is acting shady).

In my case, I get these and I am not directly using Typescript in any projects. One time VS started freaking out about some of the culture specific js files that were included as part of globalize.js - no TS in any project. Another time it refused to build a solution, pointing out a perfectly fine bit of TS in a project I hadn’t touched that it just could not resolve the types for. It also failed to compile on the DevOps hosted build server, but worked fine on every other coworkers PC.

There are a dozen other TS problem instances (all slightly different) that have been work stopping until I recode something that I didn’t change in the first place (and would be out of scope for the sprint to do so) or do something drastic like removing files from projects. This has been going on for years now. I would like VS to stop failing to compile due to TS errors when there isnt any TS present, and when I’m not touching anything that would cause any TS to need to compile (we have gated checkin, non-compile-able source cant really get into the codebase).

As I wrote before, in the error list choose build only as workaround.

@billti , I have reproduced the problem “from scratch”. here are the steps with VS 2017 Pro: 1 - in file extension : add “sql_” extension and associate it to Transac-SQL editor.

2 - Create a new solution with a C# class library (i have done both for a .Net framework et .Net standard) 3 - Remove default class file created 4 - Add a new file “whateveryouwant.sql_” to the project and put some valid SQL code inside:

SELECT 1 as DUMB_RESULT FROM DUAL;

5 - now add on typescript file “file1.ts” and put some valid ts code inside:

alert('hello');

6 - check your Error list window (it can take some time for analysis)…

Here is the solution i created

ClassLibrary2.zip

7 - If you remove sql_ extension from file extensions and restart VS, then all errors are removed.

Hope this will help for fixing issue

@guylando, the way I approached this problem in last applications, is to separate completely the folder containing the projects used by Visual Studio and the folder containing the front end source code; then I configured my JavaScript boilerplate to publish artifacts into the folder used by ASP.NET Core (wwwroot).

To develop the front end, we use Visual Studio Code, which in my opinion works much better than Visual Studio IDE for client side development.

Something like:

ProjRepository\
   \aspnet  # for server side code
   \spa     # for single page application, contains node_modules and all client source code

This also makes more sense if you are using official React or Vue.js project templates (and similar) including a Node.js development server - this is usually the case when using WebPack boilerplate.

In my case the presence of node_modules was slowing down the compilation of C# code (Why ??), even though I am working with a pretty good laptop. 😓

I found that if I select build only messages in error list, typescript errors disappear, so it seem to be issue with intellisense

Unfortunately this is not a possible workaround for us because we want to use the intellisense for other things.

Hi, I am reopening the issue because of two reasons:

• others are saying this exact problem came back with VS 15.3
• since a few weeks, Visual Studio became really slow when compiling of a solution which contains a node_modules folder (the same project I was referring to when first opening this issue)

Note that I have TypeScript extensions completely disabled; the node_modules folder is hidden in the file system and excluded from the project. Nevertheless, the compilation is impacted by the presence of this folder. The situation is even worse than it used to be, since even having TypeScript extensions disabled doesn’t help. I understand this is not exactly the same problem, but I think it may be related.

I set flag to tscofig.json "compilerOptions": { "skipLibCheck": true }

fine work for me

@gucourti we have a fix but it’s on the Visual Studio side. In the meantime we have a patch you can apply to tsserver.js:

--- "tsserver.js"
+++ "tsserver.js"
@@ -85714,6 +85714,7 @@ var ts;
                 }
             };
             ScriptInfo.prototype.getSnapshot = function () {
+                if (this.scriptKind === 5) return ScriptSnapshot.fromString("");
                 return this.textStorage.getSnapshot();
             };
             ScriptInfo.prototype.ensureRealPath = function () {

My recommendation is to keep your client side ES6/TypeScript source code in a completely different folder than the one used by your server side code and Visual Studio, and configure the build tasks to deploy client side build artifacts into the wwwroot folder of the ASP.NET Core application. I did this in the last web application I am working on. It’s annoying but it solves the problem with VS.

Please reopen this issue. This issue still occurs for me in visual studio 15.3 with following excludes I still get errors from ts files from a subdirectory of lib:

"**/wwwroot/lib/*", // Don't operate on lib directory to prevent warnings from lib code
  "wwwroot/lib/*", // Don't operate on lib directory to prevent warnings from lib code
  "wwwroot/lib", // Don't operate on lib directory to prevent warnings from lib code
  "wwwroot/lib/**", // Don't operate on lib directory to prevent warnings from lib code
  "**/wwwroot/lib/**", // Don't operate on lib directory to prevent warnings from lib code
  "wwwroot/lib/" // Don't operate on lib directory to prevent warnings from lib code