- May 27, 2017
- Posted by: Christopher Pond
- Category: DevOps
I am currently working on a new Angular 4/ASP.net 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:
Setup Visual Studio to run npm scripts from IDE vs. CLI
Install the NPM Task runner at https://marketplace.visualstudio.com/items?itemName=MadsKristensen.NPMTaskRunner.
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.
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.
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.
Once the scripts are bound you will notice this information is captured in your package.json file as follows.
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.
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 http://spartansoft.net/continuous-integration-visual-studio-team-services-angular-4-aot-build/.