Skip to content

Instantly share code, notes, and snippets.

What would you like to do?
Draft for GSoC 2016 work.

A Module system for Hammer.JS

Google Summer of code 16'


First and foremost, i would like to give a huge shout-out to my mentors Alexander Schmitz (@arschmitz) and Chris Thoburn (@runspired). Their expertise, insights and constant guidance were crucial to the completion of the project and the prime reason that it progressed this smoothly and naturally. I have learned and picked-up lots of cool stuff from them during these past months and would like to thank them for being so open, easy-to-talk to and amazingly patient with me. My GSoC 2016 experience has been a really pleasant and productive one because of them. I can now without a doubt say that i couldn't have asked for better mentors! I look forward to continue working with them in the future and contribute to open source : )


Hammer.js was not using any type of module system for managing the different files and components within the library. This project aimed at developing a module system for the wonderful Hammer.js library that is flexible, predictable and extensible in the new ES6 version of javaScript.

The advantages of organizing a program into several files or modules are similar to authors organizing a book into several chapters and sections. The structure helps people who aren’t yet familiar with the code find what they are looking for and makes it easier for the programmer to keep things that are related close together.

To achieve the above in an orderly and organized fashion, the project has been undergone in several phases, each marking a milestone in the project.

Phase I. Modularization of the library.

prior to this project, Hammer codebase consisted of several larger files containing many functions, that were concatenated together as a part of the build process to deliver a distributable. This phase aimed at breaking down these larger files into individual modules that represent and export a single functionality. A module-bundling system was required for this task, we decided to go with Rollup.js, taking advantage of the small bundle sizes and the nice tree-shaking feature.

Modularization phase of the project that was marked by:-

  • Breaking down these files into smaller atomic modular units on functional basis.
  • using ES6 import/export syntax to make these atomic modular files relate/link.
  • Make use of a module bundler i.e. Rollup to bundle these modules into the distributable file.
  • Making the distributable file configurable as per need,thus adding the ability to remove code that a user doesn't require and providing a default build similar to one provided prior.
  • Transpiling to ES5 using babel since Native ES6 modules aren't supported at most places at the time of the project.This was achieved by using the Rollup-babel plug-in.
  • Automate the transpiling and bundling of code via Rollup using Grunt.


Result ->

Hammer.js, broken down into several smaller modules using ES6 modules, making use of a module bundler like Rollup.js to bundle these together and output a distributable build similar to the one provided before by default that can also be configured as per use-case. Updated the build process by Automating the bundling and transpiling process by rollup via Grunt.

Phase II. Conversion to ES6

Hammer codebase was using ES5 javaScript, This phase of the project dealt with porting the entire Hammer library source to the next major Version of javaScript i.e ES-2015 more commonly known as ES6, making use of it's many nice features and cleaner syntax.

Features introduced via porting were:-

  • Use Kebab-casing for file names.
  • let and const replaced var.
  • Arrow functions.
  • Enhanced Object Literals.
  • Array and Object Destructuring.
  • ES6 classes.
  • Template Strings.
  • And many more.


  • Formatting.

  • Bump Ember Suave Version.

  • Gruntfile from CoffeeScript to plain javaScript.

Result ->

Hammer.js completely ported to ES6 dialect of javaScript, using it's nice features and cleaner, saner syntax.

Phase III. Modernization of Testing suite\Harness and upgrading test assets.

Hammer.js uses the testing framework QUnit for its unit testing needs. The version used the by library had gotten really old and needed an upgrade to the latest version to stay modern. Qunit introduced some major changes in its latest iteration(2.0.0) that broke stuff, thus upgrading test cases to match the newer syntax was also necessary.

This phase had clearly defined goals:-

  • Upgrade QUnit to latest.
  • Upgrade the test cases to be in sync with the updated framework.
  • Upgrade assets used by the testing suite, namely-- lodash.js, blanket.js, jquery--to latest versions.
  • Introduce management of these test assets via npm.


Result ->

Hammer.js Test harness modernized with latest QUnit testing framework, updated test cases to match the modern QUnit, upgraded test assets that are now managed by npm.


This wasn't originally part of the project plan, but after progressing with the project, it was observed that since the build process was updated, the build and automation tool the codebase was using i.e. Grunt didn't provide much utility as compared to before the project started and the tasks Grunt performed could now be replaced with native npm-scripts.

This phase comprised of writing npm-scripts to replace Grunt and Grunt-tasks in the project and thus removing the dependency on Grunt as a build tool.

  • List of npm-scripts introduced to perform tasks previously done via grunt.
    • bannerize (adds the banner ).
    • connect (serves the project on port 8000).
    • rollup (executes rollup.js).
    • uglify (uglifies and produces the min and map files).
    • string-replace (replaces {{PKG_VERSION}} with version in dist).
    • jshint (runs jshint).
    • jscs (runs jscs).
    • qunit (runs qunit).
    • watch (watch for changes in files and execute watch-tasks when changed).
    • watch-tasks (collective of tasks to be performed when a watched file changes).
    • test (collective task for jshint, jscs & qunit).
    • build (collective task for rollup, string-replace, uglify, bannerize and test).
    • test-travis (task for travis CI).


Result ->

Hammer.js with native npm-scripts to automate tasks and a removed dependency on Grunt.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment