Visual Studio 2017 npm integration and continuous integration

Most Visual Studio developers over the past year or so have probably become familiar with node packages leveraging npm as well as the acronym CI. In my humble opinion, npm does an incredible job managing JavaScript dependencies as well as managing development scripts. For some, an initial pain point with node is the dependence on CLI (Command Line Interface) which some may cause some initial uneasiness.  There are tools available to better integrate with the IDE but once you dig in and start running commands it may welcome the change.


I am currently working on a new Angular 4/ 4.x project which follows the Angular 4 AOT cookbook for compilation.  To keep the day to day development as streamlined and efficient as possible, we continue to use JIT compilation with SystemJS.  It is only on deployments that we are required to hit the command line and run our AOT scripts.

There are many obvious benefits of AOT compilation but an issue I have encountered are scenarios where a check can cause AOT compilation errors.  These errors may not be caught until future deployments or when another developer regenerates the AOT output after getting the latest source code.  The following scripts are defined in our package.json file and used for AOT builds:

npm AOT build scripts
npm AOT build scripts

Setup Visual Studio to run npm scripts from IDE vs. CLI

Install the NPM Task runner at

Adds support for npm scripts defined in package.json directly in Visual Studio’s Task Runner Explorer.

After installing the tool and right clicking on the package.json file, the Task Runner Explorer option is now available.

Visual Studio Task Runner Explorer
Visual Studio Task Runner Explorer

Initial Approach – Force AOT Compilation on Build

The npm scripts defined in the package.json file are now visible in the Task Runner Explorer window after the tool is installed. These scripts can now be run directly in IDE with all output visible in window.

run npm commands from Visual Studio
run npm commands from Visual Studio

Next we bind these scripts to the Before Build event by right clicking on the script, selecting Bindings, and choosing “Before Build” as follows:

At this point we can see both the scripts will now be run once a build is started.

npm scripts bound to Before Build Event
npm scripts bound to Before Build Event

Once the scripts are bound you will notice this information is captured in your package.json file as follows.

Visual Studio package.json binding definition
Visual Studio package.json binding definition


Introducing this step into the workflow and forcing it upon everyone was unacceptable. Considering this is a brand new project and the amount of code is far less than will be upon completion of the project, the compilation overhead was already interfering with productivity. The scripts take a while to process and running on every build did not provide much value.  Although I decided to remove the binding, we were still left with the benefit of not having to hit the command line to run the scripts any longer.

Second Approach – Developer Accountability

Accountability was discussed in the following sprint meeting.  I proposed that we all agree that the JIT and AOT compilations should build successfully prior to any check-ins.  As I anticipated, this was an unrealistic expectation for many reasons including:

  • As the day gets busy the step can be forgotten and/or pushed off to later if not enforced.
  • Perceived low risk changes can have unanticipated consequences when developing among a team.
  • Etc.

Final Approach – Success!

To insure our AOT and JIT compilation do not break on Source Control checkins, I  implemented Continuous Integration with Visual Studio Team Services. This process has caught many issues and has been an invaluable process tool.  Checkout the full case study at

Leave a Reply