#blanket.js

[alex-js]

Managing Distributables on Github

Typically when (browser based) distributables are include in a Github project they're added to the gh-pages branch.  This is done to avoid having duplicate changes in the commit logs for the source and distributable.  For example, changing a variable name in source, rebuilding, and then committing, would result in a commit containing a diff to the source AND each built distributable file.

However, there are use cases for having the distributable on your master branch, and I've developed a solution (of sorts) to make it work in a fairly clean manner.

For Blanket.js, I like to provide 4 distributable files, a QUnit and Jasmine build, and a minified version of each.  Adding these 4 files to a gh-pages branch is too much overhead.  I rebuild the project after each change to run my tests anyway, so I'd rather just have the new distributables live in master and be available after each commit to master.

Enter, .gitattributes.  Creating a .gitattributes file allows you to change the git attributes of given files.  According to the documentation you can tell git to handle your file as binary, so diffs won't be created:

`dist/*.js -diff`

In practice, this didn't work for me on GitHub (maybe it ignores the git attribute on files that have already been tracked?).  I have to change the merge attribute to union (which may not always give the intended result), but it works for me (I also run the distributables through tests on the CI):

`dist/*.js merge=union`

You can see a Pull Request without and with the git attributes in place (I'm aware that I'm probably getting the right result for the wrong reasons, but the approach should work in theory if done correctly). 

[alex-js]

Brackets + Blanket.js

Blanket.js is the code coverage library I work on, which aims to be a drop-in solution to add code coverage stats to existing test runners.  I thought I'd try adding it to the Adobe Brackets test suite, both to see their coverage details, and to check if Blanket.js is up to the challenge.

Installation & Configuration

To start, I installed Brackets.  The details for using Brackets to edit Brackets are in the article How to Hack on Brackets.

Within the /test directory, we can see that the entry point for the unit tests is the file SpecRunner.html.  This is where we need to add the reference to Blanket.js to add the code coverage functionality.

Does it Work?

My first attempt was less than successful.  I added a reference to Blanket.js right below the reference to require.js in the SpecRunner.  My mistake was using the normal Jasmine build of Blanket.js, like so:

<script src="thirdparty/blanket/blanket_jasmine.js" data-cover-only="src/" data-cover-never="['thirdparty','test']"></script>

The data-cover-only and data-cover-never attributes are set correctly (to instrument the src files, but ignore the thirdparty and test files), but the Blanket.js Jasmine adapter was in conflict with the code with SpecRunner.js.  

Blanket Adapter

Luckily, it's very easy to create a new adapter for Blanket.js.  All I needed to do was remove the code in the Jasmine adapter that binded to page load.  I've created a gist to show the custom adapter I created.

Putting it All Together

Once I updated the script reference,

<script src="thirdparty/blanket/blanket_jasmine.js" data-cover-adapter="thirdparty/blanket/blanket-jasmine-brackets-adapter.js" data-cover-only="src/" data-cover-never="['thirdparty','test']"></script>

everything started working normally and the coverage results appeared below the unit test list:

Success!

There are some improvements to be made (a dialog showing instrumentation progress, for example), but it's encouraging to see code coverage results added with very little configuration.

If you're interested in contributing to Brackets or Blanket.js please visit the source repos for details:

Brackets on GitHub

Blanket.js on GitHub

[alex-js]

Travis-Cov - CI Code Coverage Reporter for Mocha

I created a custom reporter for Mocha last week to allow builds that fall below a certain code coverage threshold to fail on Travis CI.

Basically the reporter is a fork of json-cov that does nothing with the result, except compare it against a coverage threshold stored in the consuming libraries package.json file.  If the coverage threshold falls below that number the build will fail.

It works with Travis-CI (Blanket.js is already using it!), but in theory it should work with other CI packages as well.

Check out the Travis-cov source on GitHub.

[alex-js]

Blanket.js is seamless code coverage.  It's only a basic release, but so far we're very excited about it.  Please gives us feedback or help out with the dev.

Anyway, the link above is a great summary of parsing in JavaScript.  For Blanket we used Esprima, and the slides above are a great summary of some of the issues we tackled.