The JavaScript blog.


sponsored-content build-tools build-systems wallaby.js testing build

Wallaby.js, Brunch

Posted on .


Wallaby.js, the continuous test runner that outputs results directly into your editor, currently has a 20% discount on IntelliJ Platform licenses until 7th of June 2015. There are also free betas available for Visual Studio, which usually costs $100 for a single license or $160 for a company seat license.

Wallaby.js for Visual Studio is new, and it supports code coverage, smart actions, and it has font and colour options. This is what it looks like:

Wallaby in VS

In that screenshot the green squares means that the source is covered by at least one test, and the pink square means the source is on the execution path of a failing test. The blog post on Visual Studio has more details and gifs for each feature.

In other Wallaby.js related news, it's recently got support for the Facebook Jest testing framework (which I've been using with React projects). You can find an example in wallaby-jest-sample.

Finally, Artem Govorov, who works on Wallaby.js, has been writing interesting posts about JavaScript testing on his blog. Check out Heroes of JavaScript and Testing for an amusing (but useful) overview of testing in JavaScript.


If you're not entirely happy with Gulp and Grunt, did you know there's an older build system called Brunch? It's installable with npm (npm install -g brunch), and the people behind it have created a new guide that makes it easy to get started.

Brunch is not a task runner. Gulp and Grunt are generalised task runners, and one of the reasons they exist is not everyone can run JavaScript programs can easily run a makefile. I really like using makefiles for Node projects, but Windows web developers often complain that they don't have make installed, or don't want to install it. Another reason to use Gulp or Grunt is they can provide higher-level abstractions that make reading and writing tasks easier for web developers.

So why is Brunch not a task runner? Well, it's a purely focused on asset-building. It knows about JavaScript and CSS, and can handle incremental building and smart concatenation of these files. I recently spent a good two hours combining Watchify and Browserify in a Gulp task to get incremental builds working for a React/Browserify project, but if I'd have used Brunch I could have just run brunch watch --server.

Using Brunch with an existing project might have been as much work as my Gulp/Watchify/Browserify task -- I haven't yet tried using Brunch with a big and established (OK, messy) project. I have, however, tried creating a Brunch skeleton to see what a Brunch-built project looks like, and it seems pretty good to me. If you find Gulp and Grunt hard to use then try a Brunch skeleton and take a look at the new Brunch guide.


libraries node modules npm build

Amok: Zero-Config Live Editing

Posted on .

Amok (GitHub: caspervonb/amok, License: MIT, npm: amok) by Casper Beyer is a live-reload script with a difference: it recompiles code in a Chrome debugging session, so the application's state is retained. The video for the project reminds me of Apple's Swift demos, where code is edited and you can immediately see the changes in the UI.

This re-compilation is done through a debugging session, unlike reloading or reevaluation, re-compilation leaves the application state intact, no side effects are executed when doing re-compilation.

It's also zero-configuration, so you can pretty npm install amok and then run amok. It can launch with a compiler, so you can easily run your Browserify or Webpack projects with it.

The author has made a quick video that demonstrates the main features.

If you think this sounds cool and would like to support the author, there's a Bountysource for Amok 1.0. The goals for the 1.0 version are compatibility with more pre-processors and compilers, and to research supporting other browsers. He's looking for $4,096, and there is currently $1,250 in the pot.

The concept of modifying running code using the debugger is new to me, so I really hope this project succeeds! It already has 173 stars on GitHub, but it's not quite ready for mass-adoption yet -- there are recent issues for Mac OS X and Windows support, for example.


libraries node modules npm build iojs

Node Roundup: Node 0.12.2, io.js 1.6.3, JXcore, Osmosis

Posted on .

Node 0.12.2

Is Node ramping up to regular iterative releases again? This week Node 0.12.2 was released, which upgrades the core binary dependencies, fixes a V8 issue, and has bug fixes for the core modules. Some of these commits go back to things we saw in February in io.js that I believe came from commits to Node that io.js picked up. For example, the commit for allow Object.prototype fields as labels goes back to a backport of an earlier commit.

Comparing the commits in 0.12.2 to io.js's changelog shows that most of them have already been released -- the newest commit currently in Node's stable branch was in io.js 1.5.

Speaking of io.js, yesterday io.js 1.6.3 was released. There's a bug fix for fs that stood out to me:

  • [c9207f7fc2] - fs: fix corruption in writeFile and writeFileSync (Olov Lassus) #1063

And there are several commits that improve code quality. This release seems pretty big, so keep an eye on their weekly review post on Medium for an overview.


There are more Node forks out there! JXcore (GitHub: jxcore/jxcore) is a Node-compatible platform that aims to support mobile devices. It's embeddable, supports multiple JavaScript engines (V8 and SpiderMonkey), and also supports ES6.

One of the core developers, Ugur Kadakal, sent me an email about the project, and claimed it allows applications to run on iOS. I found a blog post with more details. There's also documentation for compiling native apps with jx. I haven't tried this myself, but it sounds like they've done an impressive amount of work on it so far.


Here's a new web scraper for Node: Osmosis (GitHub: rc0x03/node-osmosis, npm: osmosis). It doesn't have any HTML parsing dependencies because it uses libxml C bindings instead. It supports both CSS and XPath selectors.

The API includes HTTP and is chainable, so you can do osmosis.get(url).find(selector).data(callback) to pull out elements for a selector. You can also open new URLs based on selectors using follow, and transform data using set().

The underlying HTTP layer is provided by needle. Needle itself is an amazing HTTP client, supporting streaming decompression, multipart forms (uploads), character encoding support with iconv-liteiconv-lite, and proxies.

If you're doing lots of scraping, then Osmosis looks like a solid library to try out. The other one that I've recently been impressed by is X-Ray.


libraries node modules npm build iojs

Node Roundup: Node 0.12.1, io.js 1.6.2, DIY, Typescript-Deferred

Posted on .

Node 0.12.1

Yesterday Node 0.12.1 was released. It has OpenSSL fixes for security vulnerabilities that include a DoS. Two fixes are ranked as high, and nine are marked as moderate.

io.js just hit version 1.6.2. The recent io.js releases have had tls and http fixes, but there are other very interesting changes if you dig into the changelog. For example, the Node binary can now be invoked with a list of modules to preload:

iojs -r foo -r /bar/baz.js -r quux  

This is equivalent to:


The reason I like this is it means environment-specific modules can be loaded without changing your code. You could use this to load modules that instrument the runtime with debugging and logging functionality.

The npm blog (yet again) has a useful post for client-side developers: Using Angular's new improved Browserify support:

With the recent release 1.3.14 instantaneous-browserification, Angular introduced better support for those using Browserify. Thank you to everyone who worked on that issue, and especially to Ben Clinkinbeard for his unflagging dedication in getting it in.

I prefer reading AngularJS code with CommonJS modules, so it would be cool to see AngularJS module maintainers using Browserify for modules on npm.

DIY: JavaScript that Compiles to a Makefile


I've used Gulp and Grunt to manage client-side builds, but as someone who used to write makefiles I'll admit to wishing everyone just used make. Well, now maybe we can, with Vittorio Zaccaria's DIY (GitHub: vzaccaria/diy, License: BSD, npm: diy).

Here's a sample configuration file:

generateProject(_ => {  
  _.collectSeq("all", _ => {
    _.collect("build", _ => {
      /* specify how to build files */
    _.collect("deploy", _ => {
      /* specify how to deploy files */

DIY is a DSL for describing build processes. The generateProject function is used to wrap calls to various methods that describe build steps. The final makefile is generated by using babel, so you just have to type babel configure.js | node. Once you've got a makefile you can invoke the targets that were defined by calls to the collect method.

This module gets top marks for using Babel and for generating something that's friendly for Unix grumps like me.


What if you want TypeScript-friendly promises? Typescript-Deferred (GitHub: DirtyHairy/typescript-deferred, License: MIT, npm: typescript-deferred) by Christian Speckner is a Promises/A+ implementation written in TypeScript. The author says nobody needs another promises implementation, but this implementation is pretty cool: it has no dependencies, and fully implements the specification.

If, like me, you're a TypeScript tourist, then here's what strongly typed promises look like:

// A promise for a number that resolves to 10
var promise: tsd.PromiseInterface<number> =  

// A promise that adopts the state of some other thenable that wraps a value
// of type sometype
var promise: tsd.PromiseInterface<number> =  

Christian suggests that this will be useful if you want to embed a small promises implementation into your own libraries.


grunt build

Build Configuration with Angus

Posted on .


Build tools are great, but they're usually optimised for working on single projects. If you're a freelancer or work for an agency, then you probably work on multiple projects for several clients each day. Angus (GitHub: nickjanssen / angus, License: MIT) by Nick Janssen aims to help improve exactly that type of workflow by sharing a build configuration across all of your applications.

Angus solves these problems by turning the build process into something generic and reusable. It allows you to specify libraries on a per-app basis, while still sharing the same build steps.

Inside Angus, every app is simply a directory inside the apps/a folder with its own repository. The apps/ folder gets ignored by the Angus repository. Each app you make with Angus shares the same globalGruntfile`, but can define all the libraries they need on a per-app level.

Each application can still have its own dependencies. Bower is used for client-side dependencies, but rather than using bower.json files Angus invokes Bower with the necessary package names and version strings.

Nick posted an article to David Walsh's blog about Angus: Building Web Apps Faster Using Angus. It details the installation and configuration process and also shows how to use Angus with Git.