Visual Studio 2015/2017 .tsproj project type suggestion

[atomsoftwarestudios]

What I am really completely missing in VS(15/17) is a pure TypeScript project (without C# or anything else).

Why I am missing it?

The HTML App with TypeScript project is great, it allows me to develop, debug, sync repos, run gulp tasks, everything is perfect (except debugging over Chrome Debugging Protocol which is quiet complicated to achieve - in 2015, 2017 probably changes this, but I didn't try yet), but...

As I am focusing on front-end only I don't need anything else in background. I am not developing IIS modules and my back-end is separated in a different solution so I don't need C# or Asp.Net at all. Compilation of the C# code slows down build process dramatically (especially when I have multiple projects with some dependencies in the solution) and is completely useless for me. I would say developers focusing on Angular apps developing in TS in VS will agree.

So what I am basically missing is a project extension (.tsproj would sounds good :) which will allow me to:

• Develop TypeScript Web Apps including standard web resources (html, 3rd party javascript, images, stylesheets, less/sass stylesheets, jsons, MD's, xmls... whatever is possible to do in Asp.Net app so the project items should be almost the same)
• Multiple projects per solution with dependencies (same way as in C#) so build order is followed and it is possible to use one project as a library in another. It would be great to find a good mechanism to copy transpilled .js and .d.ts filed to consumer projects as C# is doing it. But clean should be working correctly and remove also these files :)
• Same support for tsconfig as there is already with small change: internal support for Debug/Release configurations (I am currently using tsconfig.json, tsconfig.common.json, tsconfig.Debug.json and tsconfig.Release.json where tsconfig extends Debug or Release based on solution configuration - achieved by a prebuild script now and Debug/Release extends common to avoid need of writing same options multiple times so if this can be included it would be great)
• CompileOnSave feature should be working for TS files, for rest of resources custom actions should be possible to execute (such as starting a batch file or .js files in Node.js to perform the custom action). This would be great for css transpilation, image processing, resource bundling and so on).
• Build - this could be designed in the way the debugging / IIS would not need to be stopped/restarted during build (only if Debug/Release changes). Build should allow the same tasks mentioned: compilation of projects in the solution in correct order, resource processing, packaging - based on configurable custom actions (execution of some scripts during the build process - at least pre/post build)
• Run - standard IIS Express with possibility to modify web.config and application.host config files as necessary (basically, as it works now in Asp.Net projects). Debugging of the IIS Express process itself can be omitted as there should be nothing to debug on the web server side
• Debugging - I am fine with IE11 debugging (if I need I am using internal chrome/firefox debuggers out of VS) but it would be great to have possibility to debug over Chrome Remote Debugging Protocol as it is supported by multiple browsers
• Configuration of browsers for start/debugging should be also possible as it is now
• Web Publishing (the same way it works now, but just for front-end files. .dlls for IIS modules and Asp.Net applications for IIS can be omitted)
• Repo management (the same way it works now with i.e. Git extension for VS)

[billti]

Thanks for the feedback. This is definitely something we've been discussing for a while, and hope to add at some point. The idea of a "JavaScript library" that can be built then referenced across projects in the way a DLL or WinRT component can is appealing.

For right now, have you looked into the Node.js templates available (if the Node.js workload is installed in VS 2017, or by installing the NTVS extension as part of VS 2015)? As you mention above, it's quite common to use Node.js in the process of building libraries (for minification, bundling, etc.), so being an actual Node.js project is a natural place to host a project that produces a JavaScript library. It can also spin up a simple Node.js hosted server (e.g. Express, or http-server) for hosting/debugging, avoiding the need for IIS Express or C# assets.

Project to project references and managing build order within the tooling are still missing, but that does get you some of the way there. We'll definitely be working towards a better solution long term though.

[benaadams]

I'd like a typescript lib project; happy to then build the output js and map files into the scripts folder of my other projects that use it. Typescript Node project sorta works...

[benaadams]

For example Babylon.js uses .csproj for this, which isn't ideal https://github.com/BabylonJS/Babylon.js

[NoelAbrahams]

This issue has been on User Voice since Oct-2012. And in fact is the suggestion with the second most number of votes.

So I would take comments about this being fixed with a pinch of salt.

Visual Studio related work is generally not a high priority for TypeScript.

[johncrim]

The old UserVoice issue was closed - the new UserVoice issue is here.

I think a typescript-specific project type would be useful (with the typescript configuration in one or more .tsconfig files), but I also think there's a strong need for a web UI project type, which also isn't supported in VS 2017 currently.

[NoelAbrahams]

Added a comment on the issue on user voice which I'm reproducing here:

There should ideally be two JavaScript/TypeScript project types:

1. A Library Project Type

Current workaround is to use a C# or ASP.Net Web Application project type.

Problems

• Firstly for a project that only contains JavaScript/TypeScript files, it is not clear why we are even working with C#.
• Secondly loading C#/ASP.Net build targets when the whole process is actually handled by the TypeScript compiler is a waste of computing time.
• Thirdly the build project generates "*.dll", ".pdb" and junk in "obj" directories. We are only working with JavaScript output and there is no need for any of this.
• Fourthly, the project xml contains a listing of all files in the project. Since .tsconfig ignores this list, the project xml should not list any files at all; it should simply contain the MSBuild logic.
• Finally, I don't want screen real estate taken up by unnecessary features such as "Properties", "References", "Connected Services", "web.config" etc, which are all a part of these "workaround project" types.

2. A Web Service Project Type

Currently handled by the NodeJS Web Application (NTVS) project type

Problems
Although many of the problems above also apply to NodeJS projects, the biggest problem by far is that NTVS appears to have been started off as a side project and the fundamental quality of the project is rather poor. One only need look at the NodeJS targets files (C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Microsoft\VisualStudio\v15.0\Node.js Tools) to see the amount of confusion and junk that is present there. The complete lack of responses to issues raised points to a complete lack of maintenance for this project. Raising issues on user voice doesn't seem to do any good either.

This is a serious concern for us. Performance improvements to the TypeScript compiler are vastly overshadowed by time spent in compiling the "workaround projects" in Visual Studio.

I just want to "Add -> New Project -> Library|Web Service and get on with it, without having to suffer performance issues and having to carry along excess baggage required by C# and ASP.Net.

[fowl2]

seems this is a dupe of #11?

[bertutron]

can someone explain to me why there is still no typescript project type? first issues about it were raised 2014, and typescript is basically web standard by now. ignoring typescript - developed by microsoft btw - is a bit ridiculous. nodejs projects are just a workaround, no solution.

[joj]

We do have a JavaScript project type now. The extension is .esproj and it can be used as a library for ASP.Net, but it's still very early and feedback on scenarios where it isn't doing what people want will be appreciated.

[johnwc]

We do have a JavaScript project type now. The extension is .esproj and it can be used as a library for ASP.Net, but it's still very early and feedback on scenarios where it isn't doing what people want will be appreciated.

@joj Is there example projects showing an .esproj as library for ASP.Net project?