The state of Angular 2 Tooling


The Angular 2 framework has now been released so it’s a great time to jump in and learn the ropes. However, whilst we can relax our attention on the changing API’s in the framework for a short time, we’re still faced with the endlessly changing world of front end tooling.

Webpack is currently top of the pile for all of our developer workflow needs. But what else is there and where do we start?

Angular cli

A fork of the ember cli that’s recently been updated to support webpack replacing systemjs. This is almost certainly going to be the dominant player going forward as it has some prominent angular community contributors. Remember that much of the featureset comes from webpack rather than the cli itself.

  1. Your lowest friction option for getting a project up an running.
  2. The generators are really useful for creating the often repeated boilerplate in an Angular app.
  3. The generators help maintain consistency across an application in the absence of existing coding standards.
  4. Built on test first principles. Unit and e2e tests are baked into the generators.
  1. Performance overall is mediocre. Initialising a new project or running tests for the first time can be very slow.
  2. Still in beta and past changes show they’re not afraid to move the goal posts by quite some margin.
  3. Currently no OOB support for cache busting in the webpack build.
  4. The inline help system isn’t good.
  5. Due to the development cadence it’s difficult to get answers to problems. Most answered questions on stackoverflow are long out of date.

ASP.NET Core Yeoman generators

If you’re looking at developing an Angular application using ASP.NET Core for the backend these generators are worth a look.

This is a great video by Steve Sanderson at NDC Sydney 2016 discussing their capability in some detail.

Community Starter Templates

These are a couple of github projects that provide a basic application along with some preconfigured tooling. Generally they’re going to provide the same bootstrapped project experience as you’ll get from the angular cli but in a slightly lighter touch template.


Low touch template with testing baked in and a solid README to get you going. As of this writing still being updated regularly.


Gulp based build – not a bad thing! It’s an older project but it’s still being updated. Again the README is solid and there are a number of forked reference sites linked that may prove handy.


Obtaining Typescript Definition Files


typings or the types npm organisation?

In this post I’ll look at the current options available to us for managing the definition files (d.ts) in our typescript projects.

I recently started looking at the new features in typescript 2.0 and was surprised to find that tsd has been deprecated. The deprecation isn’t part of the 2.0 release as tsd is/was just external tooling but it quickly became part of my refresher that I thought I’d share here.

As a quick update tsd was a command line tool that allowed you to pull type definition files for external libraries (lodash, jquery etc) into your project.

I discovered we now have two options available to us that initially caused me some confusion as I wasn’t sure if they were related in some way. They’re not.


The typings project is a community supported option hosted on github that has been the primary replacement for tsd. It allows you to pull in definition files from a number of sources and continues to be supported. It has a solid upgrade path if you’re moving a project from tsd.

View the README on the project repository for more info.

@types (organisation on npm)

The @types organisation on npm has been created by Microsoft as a response to the communities feedback that obtaining definition files has been troublesome. At the time of writing the organisation contains 2247 separate packages. Since this is a regular npm repository you’ll just install the definition files as regular npm packages using the @prefix for the org:

npm install @types\lodash.

The repository is populated from a publisher service that continues to pull the definitions from the DefinitelyTyped repo. You could use it for pulling into a private repo if required.

Going forward I think I’ll be using @types. However, the new angular-cli uses typings which is how I was introduced to it’s existence. It’ll be interesting to see if they continue to use typings or move over to using @types.

I’ll be publishing another post soon describing how to configure a new typescript project to use @types.

Further reading:

Microsoft Blog Post – The Future of Declaration Files