This suggestion is migrated to Developer Community. Please use below link to view the current status.
Please vote and add comments below to indicate what kind of features you would like this project type to have.
Noel Abrahams commented
This should ideally be two project types:
1. Library Projects (current workaround is to use a C# or ASP.Net Web Application project type)
* Secondly loading C#/ASP.Net build targets when the whole process is actually handled by the TypeScript compiler is a waste of computing time.
* 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. Web Service Projects (currently handled by the NodeJS Web Application (NTVS) project type)
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.
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.
Best solution I found so far is a shared c# project (although file nesting won't work).
Second best solution is an empty asp.net core project.
Both supports well node_modules folder (i.e.: keep it hidden and out of visual studio), where asp.net core automatically add new files to the project and shared c# project you need to add them manually.
Both work fine with ReSharper.
Currently, I use Node.js project(from Node.js Tools extension) for my pure TypeScript project. It works but there are so many bugs. It's far from perfect.
I just don't understand why Microsoft don't implement this kind of project into Visual Studio 2017.
John Crim commented
My use case: We put UI code (eg npm package.json, html, angular typescript) in a separate directory + project from our server code. UI developers can run webpack and either proxy a local server (on the dev host) or use an integration server.
It gets too messy to combine UI code and Server code in a single project + directory (as the `dotnet new angular` template creates + requires). The `dotnet new angular` template is useful for demos, but is not useful for production sites. I've tried using that template for our site, which runs webpack in the server, but the abstraction was not usable with a separate UI project directory.
In VS 2015 we used the node project type to contain UI code, but that wasn't ideal b/c we didn't need node (server) debugging, we wanted browser debugging. The only useful bit about the node project type was the support for npm dependencies and npm scripts and showing npm/gulp builds in the Task Runner Explorer window. And it seemed to be compatible with typescript syntax highlighting and intellisense.
In VS 2017, there is no node.js tooling (yet), but even if there was, it's not ideal as mentioned above. For now we're using a separate SDK-style .csproj to hold all our angular UI code, because no better project type for holding this code seems available. There is no C# code in this project, so it's clearly the wrong project type.
I'd like a project type that works well for holding package.json projects (and support using either yarn or npm ideally), with tsconfig.json and typescript intellisense, and support for tslint.json. It should work for webpack builds.
As a minimum, I would be happy with a project type that just holds files, and supports settable build, clean, and rebuild targets, and a settable "start" command-line with optional support for attaching a debugger to a browser.