I suggest you ...

Create a JavaScript project type

This suggestion is migrated to Developer Community. Please use below link to view the current status.
Provide a new project type in Visual Studio that focuses on developing JavaScript and TypeScript projects.

Please vote and add comments below to indicate what kind of features you would like this project type to have.

54 votes
Sign in
Sign in with: facebook google
Signed in as (Sign out)
You have left! (?) (thinking…)
AdminVisual Studio Team (Product Team, Microsoft Visual Studio) shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


Sign in
Sign in with: facebook google
Signed in as (Sign out)
  • Noel Abrahams commented  ·   ·  Flag as inappropriate

    This should ideally be two project types:

    1. Library Projects (current workaround is to use a C# or ASP.Net Web Application project type)

    * 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.
    * 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.

  • Anonymous commented  ·   ·  Flag as inappropriate

    I want to create purely client side javascript, so minimum platform would be more like ECMAscript version or javascript engine. Having DOM objects would be very useful too.

  • JCKödel commented  ·   ·  Flag as inappropriate

    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.

    The ideal solution would be if we could add a folder in a solution (File -> Open Folder). Today, open folder opens a folder (like Visual Studio Code), but closes the current solution (so it is useless in an hybrid C# backend/javascript frontend project).

  • Soul_Master commented  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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.

    In general I think simpler is better for a Javascript project due to the variety of approaches that developers take with UI code builds. VS Code works much better for this type of project b/c it is a thinner layer over the directory plus command-line. In my opinion it should be possible to edit typescript and javascript files in Visual Studio, and debug browser code in Visual Studio, without preferring VS Code for UI dev and Visual Studio for Server dev.

    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.

Feedback and Knowledge Base