Enforcing JavaScript Quality Standards using JSHint Sharable "Configs"

This article is relevant for: 
- Grunt version 1.2.4
- grunt-contrib-qunit version 0.3.0
- HTML5 Thor version 1.1.3
it may or may not work for other versions.


If you are using JSHint as your JavaScript quality library then you know how good it is. If you use or have used JSLint then you probably get frustrated at the amount of warnings/errors it throws and you discontinued using it, but JSHint is a community driven layer that sits on top of JSLint that makes JS quality standards more realistic to follow.

I'm currently working on a App SDK for Foxtel so developers can build and deploy apps to a Set Up Box environment with ease and at the same time follow strict quality guidelines.

The SDK is based on my open source project HTML5 Thor so if you want to follow along this guide or want a HTML5 tooling platform for web apps your can check that out.

Basically, our app can use a simple Grunt workflow to do things like testing, building, deploying etc and to ensure that your app is of industry standard quality you set up a Grunt task that uses JSHint to check your JavaScript files during the crucial steps (i.e. build, deploy etc) and only proceed if the quality is acceptable. Now if multiple developers are working on your app or your app is actually a framework that will be used by other app developers then you need someway to share a common JSHint configuration that all coding work involving your app/framework follow a common central standard.  For this we will use the Grunt plugin grunt-contrib-qunit.

Let's dissect this workflow a bit so we can understand how it works. Let's use HTML5 Thor for this.


Step 1:
Follow the Setup instructions shown in the Repo Readme and get HTML5 Thor running on your system.

Step 2:
Navigate to the html5-thor app folder, and type -
grunt jshint

You will then see this result that says that all your files are lint free.

Step 3:
Now let's open up our gruntfile.js and see the JSHint settings we have used to get this working.

• First, you can see from line 105 that we are using the 'grunt-contrib-jshint' plugin for JSHint checking
• Next in line 114 you can see that that as part of our 'package' process we first run the 'jshint' task and only continue to the remaining steps if this passes
• From line 80 you can see that we have given the 'jshint' task settings
• In line 81 we say point to the JS files we need to check (bower.json, package.json etc). the 'src/js/**/*.js' is a wildcard to say check all .js files in the src/js folder
• In line 83 we say what we want to ignore
• And finally and most importantly (as this is what this Blog post is about), we say to use "Custom JSHint" rules as given in a file called '.jshintrc' which sits in the root on your app like so

Conclusion:

Basically, this makes the JSHint standards 'Portable' where you can share and exchange the rules with your developers so they can all follow the same implementation of the JSHint standards.

I personally maintain my own preferred '.jshintrc' standards as a separate Github project and add version control to it as I learn more about JSHint and want to keep updating the governance of the Apps and Frameworks I build. I can then just update the version of the '.jshintrc' file in any app and automatically get new standards of quality governance.

To see what this '.jshintrc' looks like check out my jshint-config-template project.