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