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.
Here are some recommendations for setting up your environment so that the code you write smells like the main project.
- editorconfig so we have the same spacing style
- jshint for all files (we have a .jshintrc, and lint is run on every commit with travis)
- phantomjs - to automatically run all the qunit tests for you
- casperjs -
- Mac -
brew install casperjsAdditional instructions
- Mac -
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:
grunt testwill run the qunit tests
grunt server casperjswill 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. Full tag listing
Grunt tasks for release:
test, and other sanity checks
- minify (create pilotfish.min.js)
- Generate documentation
- Copy pilotfish.js and pilotfish.min.js to:
- git add/commit files in /dist/
- git push with tags
grunt release_cdn. This is how files get to http://cdn.pilotfish.io/client/. Assumes that the pilotfish.github.com repo is checked out at in the same directory as this repo.
- Santy checks
- copy the files from dist to ../pilotfish.github.com/client/
- git add/commit
- git tag with current release.
- git push (with tags)
grunt --help for more info.
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
- 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
windowwhen 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! :)
Here are a few interesting resources: