Skip to content

Aquent | DEV6

Generic selectors
Exact matches only
Search in title
Search in content
Search in posts
Search in pages

Angular 2 Tooling

Written by: Alain Thibodeau

Front-end web development moves at a fast pace and the tooling moves even faster. It wasn’t long ago that an editor and the script tag were sufficient to build an application. Our local development workflow was minimal, deploying meant opening an FTP client and uploading the files. The biggest decision was picking an editor. The process back then was simple; the need for a build process was laughable. Times have changed.

Today, browsers are more advanced and applications are more sophisticated. Having a build and environment workflow is now required. Before going to production, we need to process our application files for: concatenation, minification, timestamping, versioning, etc. The introduction of JavaScript supersets like TypeScript force us to transpile our code. And now, modules add another layer of processing, as we need to load modules in order and bundle them. All of this means that having a good toolset and workflow is necessary for being more productive and building a great application.

Setting up a workflow for Angular 2 can be frustrating and confusing. The extensive list of choice out there is overwhelming and some tools overlap in functionality. While we all have preferences when setting up our workflow and which tools we use, decisions need to be made. The specific needs for the application being developed need to be addressed. Generally, after trying out a few options we settle on the configuration that works for us and the types of applications we build. Ideally, we want to end up with a workflow and a set of tools that work for us rather than against us.

I’ve gathered a high level overview of the current state of tooling for Angular. I’ve tried to address every aspect of development. These are not all the tools out there, but the tools that stand out the most.

Task Runners

Simply put, a task runner… runs tasks (it manages the execution steps required to build your application, and more). It automates the repetition during the development process. Watching files, linting files, concatenating files, unit tests can all be ran by task runners. It lets you concentrate on developing the application instead of continuously manually running them.

Grunt and Gulp

There are several task runners out there. Grunt and Gulp are the two that almost always come up when talking about JavaScript task runners. There are plenty of discussions about which one is better, so I will not get into that here. I’ve used both and I like both. The key difference is that Grunt is configuration oriented and Gulp is more script oriented (“code and pipes”). Your Gulp file will most likely always be smaller than your Grunt configuration. The Grunt file is all configurations. If you have a need for custom quick processing or changes you have to create a custom task. With Gulp you can just modify what you need right in the Gulp file.  Gulp is faster and easier to set up than Grunt. So in the end these are some of the key differences with task runners and the preference is yours.

NPM Scripts

It is worth mentioning that you may not even need a runner on smaller projects. It turns out that NPM has the ability to run scripts. Since everything that a task runner runs ultimately can run on the command line, we can just invoke those commands via NPM scripts. This can simplify the whole workflow greatly and reduce your node package dependencies. There comes a point however if you need to pass in too many configurations that the scripts become too long and hard to follow. This is the point where you should consider a task runner such as Gulp or Grunt.


It goes without saying that testing your applications is very important and dare I say should be mandatory. The Angular team has made it very easy for us to test our code and it is becoming easier and easier as time passes. Testing by itself is its own domain and one could spend a whole career doing it. Fortunately, the tooling for testing is straightforward and easy to set up even for the novice tester.


Karma is a test runner that like all other tools runs on node. The Angular team created it but it is important to note that you can also test non-Angular applications with it. This unit-testing tool allows you to run your tests against any browser or platform. This highly configurable tool has great plugin support with coverage and test results. Karma also allows you to use your test framework of choice such as Jasmine or Mocha.


Integration or “end-to-end” tests are also very important. We use a tool called Protractor to run this type of test. Also created by the Angular team, Protractor is built on top of Selenium’s WebDriver. This allows us to tests the application in a browser and simulates a user navigating our application. This is very helpful for scenarios where we want to test our new features works as expected or that there are no visual issues with our application.

These are an important addition to unit-tests since they exercise how the units “integrate” with each other from the beginning to end of a user session. The units may work well on their own (“in a vacuum”), but perhaps there is a problem when one unit is executed before another and integration tests will help catch those issues.

Angular 2 Specific

In most scenarios the tools mentioned so far are sufficient for AngularJS 1 applications. However, for Angular 2, the set up is now more involved. With the arrival of ES6 and Typescript along with modules we need extra steps, tools and decisions.


TypeScript is a scripting language created by Microsoft (now in partnership with Google) to move web standards forward. It brings more Object Oriented Programming concepts to web application scripting, not to mention strict typing, code shortcuts and other benefits.

For various reasons, it is recommended to use TypeScript with Angular 2. For the most part the TypeScript compiler is all you will need for ES6 support. TypeScript is following along with the new features of future versions of JavaScript. It does a good job at keeping up to date. For edge cases you may need to use Babel or Traceur, but unlikely. Either way, using a superset of JavaScript now means we need to transplile. Typically you would use the tsc compiler in your set up, which requires a configuration file usually named tsconfig.json.

Another thing to remember with TypeScript is that it does not always understand external libraries. If the external JavaScript library being brought in does not have type definitions, then you need to use the typings tool. This tool searches for community driven definition files. 

To learn more about setting up TypeScript and Typings for your Angular 2 project, head on over to the Angular 2 documentation and the TypeScript documentation.

Sign up for our Angular Course

Learn the most recent version and start building your own Angular apps

view course details


At the moment modules are a very heated topic. The ES6 specification for authoring modules was completed recently, which is great because this gives us a module format to use moving forward. It ends the so-called module format wars. However, the specification for loading modules was pushed off, as it wasn’t ready. As browsers currently do not understand how to load modules we need to use outside help.

There are several solutions out there for module loading and selecting the right one really is up to you. In fact the Angular team currently does not really suggest one over the other they just make sure that Angular works with all of them.

At a minimum the tool you pick must be able to load the module format you export from the TypeScript compiler. Then, you may want that tool to create bundles or take advantage of tree shaking (to eliminate unused library code). For Angular 2 the two tools that stand out are Webpack and SystemJS.

SystemJS & JSPM

SystemJS on its own is a module loader that can load all types of modules such as ES6, CommonJS and AMD (Asynchronous module definition). It is what the Angular team has used in their latest quick start guide. There is minimal setup and it works well out of the box. If you want to create bundles then you need to use JSPM on top of SystemJS. JSPM is the package manager for SystemJS, which also allows you to create bundles. Check out the SystemJS and JSPM websites to find out if these tools are for you.


This tool is a treasure chest of functionality and works with all types of modules just like SystemJS. This is the tool that I have adopted and it is working well thus far. Module loading and bundling is the core purpose of Webpack. But, it can do much more. At its core it considers everything a module, including your images and styles. It has a great plugin system that covers most, if not all, of your needs.

Since Webpack processes files, you can remove any task runner you are using such as Grunt or Gulp. Webpack will take care of loading and bundling your modules as well as linting, transpiling, source maps etc. Everything you need to create a production ready application. One of its best features is the hot module swapping which updates only the code that has changed. This means that while developing locally, the browser never refreshes after you make a change and the code that was affected still gets updated in the browser.

I will admit that the documentation for Webpack is not the best, but you can check it out and decide for yourself. The Angular team has also just added a Webpack introduction.


Debugging web applications can be tricky but the tools are getting much better than before. Most browsers now have great developer tools such as the Chrome developer tools. Using the Chrome developer tools allow you to see pretty much everything that is going on under the covers in your application. For example the tools show you server calls, the DOM tree, and memory usage. If you are using source maps with TypeScript you can see the JavaScript code and use breakpoints. You can also emulate devices and network speeds. This just scratches the surface, for more on Chrome developer tools read the documentation.

These are great tools, but there are a few more specifically for Angular 2.


This open source tool is meant to help you visualize your Angular application. It allows you to see your component relationships, router structure and dependency hierarchy to name a few. Formerly known as Batarang this tool installs as a Chrome tools extension and you can find out more about it here.


Recently the Angular team has released the Angular 2 style guide. It is great that they have released the guide at this time. Moving forward you will be able to use this to structure and build your applications properly as you learn Angular 2. A guide such as this was not available for AngularJS 1 until some time after its release. So, we welcome this guide, allowing us to move in the right direction.

Taking it a step further is Codelyzer, which is a tool that enforces the Angular style guide during development. This is great because if your code style deviates from the style guide, Codelyzer will warn you and even provide a link to the relevant part of the style guide. Codelyzer piggybacks on TSLint in its configuration where you add it as a rules directory. Find out more, head on over to the github page for Codelyzer. It is optional of course, so you can deviate from the style guide without harassment if you choose.

Angular CLI

If you have read this far and you are still with me, congratulations. As you can see, the tooling for Angular 2 applications can get quite involved. The Angular team knows this. So, they are creating a tool called Angular CLI. This is a scaffolding tool with the goal of getting you set up quickly and becoming your partner during development by providing automation for common development tasks.

The goal is to remove the need for many of the above tools and do it all for you with a few simple commands. If you are hands on and like to avoid tools that do it all for you, this might scare you away. However, it is in the early stages and time will tell. You can see it in action as it was shown during ng-conf a few weeks ago. If you want to try it out head over to its github page and give it a spin.

Before you go…

As we have seen there is a lot of choice for your environment set up and the tooling that you pick. Ultimately, the decision is yours. I summarized the currently most popular tools and some that are in the works. Having said that, the tooling landscape for web applications can change quickly. I will leave you with these parting words: It is healthy to re-assess your toolbox and clean it out once in a while. Especially when starting with a new platform like Angular 2 and also with incomplete specifications such as module loading.