Skip to content


Subversion checkout URL

You can clone with
Download ZIP
Fetching contributors…

Cannot retrieve contributors at this time

90 lines (65 sloc) 4.664 kB

Pilotfish development guide

You are welcome to fork this repository. We'd love getting pull requests. We work in master, so if it's committed there it's assumed that it's good to go live. We'll likely develop a more advanced branching strategy later.

Environment Setup

Here are some recommendations for setting up your environment so that the code you write smells like the main project.


We recommend Test Driven Development be used, and we aim for 100% coverage. If you use grunt watch, you can have it run the tests every time you write a file.

We use travis-ci for automagic testing on every commit. Current test status:

Build Status

Running Tests

  • grunt test will run the qunit tests
  • grunt server casperjs will run all the casperjs tests


To release, the files are run through a set of checks and then copied to the /dist/ directory. The minified versions are also created, along with any building of CSS or images.

We tag them in git with release/$version, making it easy for folks to go to that point in history. For example, to see where it all started, check out the 0.1.0 version of Pilotfish. Each plugin also has it's own version, and releases are tagged as release/plugin/$plugin/$version.

Grunt tasks for release:

  • grunt release_core
    1. lint, test, and other sanity checks
    2. minify (create pilotfish.min.js)
    3. Generate documentation
    4. Copy pilotfish.js and pilotfish.min.js to:
      • /dist/latest/
      • /dist/$major/
      • /dist/$major/$minor
      • /dist/$major/$minor/$patch
    5. git add/commit files in /dist/
    6. git push with tags
  • grunt release_plugin[:$plugin]
  • grunt release_cdn. This is how files get to Assumes that the repo is checked out at in the same directory as this repo.
    1. Santy checks
    2. copy the files from dist to ../
    3. git add/commit
    4. git tag with current release.
    5. git push (with tags)

See grunt --help for more info.

Coding Philosophy

In order to ensure high quality code, we ask that contributors follow some coding standards.

Our overarching principals are simplicity, readability, and maintainability.

This should be fun!

Pedantic coding standards

Most of the suggestions below apply to Javascript in specific, since most of the project is written in javascript. For the most part, we follow the jQuery Core Style Guidelines, but we'd like to call out the following additional points:

  • Spaces, not tabs. 4 of them. Pro tip: Use an editor that supports editorconfig, and this will be handled for you.
  • Minification is the computer's job, not yours. Use explicit variable names.
  • Braces on the same line, or I am afraid this won't work out.
  • Cleverness is seldom required. When it is, comment it.
  • Be considerate of other contributors. Will someone who reads your code later understand what you've done?
  • Names matter. Use names that make sense for clarity.
  • Minimize the use of assumed globals, explicitly reference window when you need to.
  • Always use semicolons;
  • Always use braces, no one-line shortcuts.
  • Triple equals where it is a good idea. Don't leave type to chance.

Have a suggestion? Fork this page and issue a pull request! :)

External resources

Here are a few interesting resources:

Jump to Line
Something went wrong with that request. Please try again.