Look into hooking up jscs/jshint to travis

[taylortom]

Support for jshint/jscs has been added here, but compliance is currently at the individual developer's discretion.

Would be nice to get this enforced in someway -- either as a git hook to be called on commit, or at the travis ci level.

I'm all for the consistency that this should bring, but think we need to be careful that we're not too strict with the rules, as will likely cause many 😠💢✊

[moloko]

yeah the danger here is that - because we are adding this after the majority of code has been written - lots of existing stuff will be flagged the first time it's run. so whoever does the first commit/push is going to be hammered with all the existing issues!

[taylortom]

Yeah exactly. A solution could be to add a very bare-bones configuration (i.e. stuff we definitely don't want to get through like using the wrong number of spaces/tabs or whatever), and just let everything else be up to the dev.

[taylortom]

Have set up a test. See the following for more details:

• .travis.yml
• v2_build_test.sh

Main test consists of:

1. jscs
2. jshint
3. grunt build (output suppressed on travis-ci.org)
4. An attempted build of the updated framework against v2.0.0 core plugins

A failure during any of the above will result in an overall task failure.

Also added a webhook for integrating with gitter (linked to one of my own private chats in this test)

My tasks in script will override anything found in scripts in package.json (not currently used), not sure if this is an issue or not. I thought this way was more self-explanatory, as the entire travis test process is listed in the .travis.yml.

[moloko]

see #2377