grunt-coffee-jshint
v2.0.1
Published
grunt wrapper for coffee-jshint
Readme
grunt-coffee-jshint
Grunt wrapper for coffee-jshint
NOTE: As of version 2.0.0, grunt-coffee-jshint depends (through coffee-jshint) on coffeescript in
favor of the, now deprecated, coffee-script name.
Getting Started
This plugin requires Grunt >=0.4.1
If you haven't used Grunt before, be sure to check out the Getting Started guide, as it explains how to create a Gruntfile as well as install and use Grunt plugins. Once you're familiar with that process, you may install this plugin with this command:
npm install grunt-coffee-jshint --save-devOnce the plugin has been installed, it may be enabled inside your Gruntfile with this line of JavaScript:
grunt.loadNpmTasks('grunt-coffee-jshint');The "coffee_jshint" task
Overview
In your project's Gruntfile, add a section named coffee_jshint to the data object passed into grunt.initConfig().
grunt.initConfig({
coffee_jshint: {
options: {
// Task-specific options go here.
},
your_target: {
// Target-specific file lists and/or options go here.
},
},
});Options
options.jshintOptions
Type: Array
Default value: []
A list of JSHint options to pass on as the coffee-jshint --options option1,option2,option3,etc,... argument.
For more information about these, please see JSHint's options.
options.withDefaults
Type: Boolean
Default value: true
If you want to turn off the default options for coffee-jshint, change this flag to false.
This is the equivalent of doing coffee-jshint --default-options-off.
For a list of coffee-jshint's defaults, please see its options.
options.globals
Type: Array
Default value: []
A list of all globals in the project.
This option is passed on as the coffee-jshint --globals global1,global2,etc,... argument.
See also coffee-jshint's globals.
Usage Examples
Custom Options
In this example, some globals and jshintOptions are defined at the task level options, sometimes to be specifically replaced with target level
definitions. For more information on what they do, please see JSHint's Enforcing options, Relaxing
options and Environments. The latter group let JSHint
know about some pre-defined global variables so that you don't have to explicitly include them into globals.
grunt.initConfig({
coffee_jshint: {
options: {
globals: [
'define',
'IntersectionObserver',
'Symbol'
],
jshintOptions: [
// Environments:
//
'browserify'
'browser'
'devel'
// Enforcing options:
//
'eqeqeq',
'forin',
'noarg',
'nonew',
'undef',
'unused',
// Relaxing options:
//
'debug',
'loopfunc'
]
},
app: {
files: [ ... ]
},
gruntfile: {
options: {
globals: [],
jshintOptions: [
// Environments:
//
'node'
]
},
files: [ ... ]
},
test: {
options: {
jshintOptions: [
// Environments:
//
'jasmine',
'node'
// Enforcing options:
//
//... likely copied from task level `options.jshintOptions`
// Relaxing options:
//
//... likely copied from task level `options.jshintOptions`
]
}
files: [ ... ]
}
}
});Contributing
In lieu of a formal styleguide, take care to maintain the existing coding style. Add unit tests for any new or changed functionality. Lint and test your code using Grunt.
Prerequisites
Setup
Clone this repository somewhere, switch to it, then:
$ git config commit.template ./.gitmessage
$ npm installThis will:
- Set up a helpful reminder of how to make a good commit message. If you adhere to this, then a detailed, meaningful CHANGELOG can be constructed automatically;
- Install all required dependencies;
Commit
Commit Message Format Discipline
This project uses conventional-changelog/standard-version for automatic versioning and
CHANGELOG management.
To make this work, please ensure that your commit messages adhere to the
Commit Message Format. Setting your git config to
have the commit.template as referenced below will help you with a detailed reminder of how to do this on every git commit.
$ git config commit.template ./.gitmessageRelease
Determine what your next semver
<version>should be:$ version="<version>"Bump the package's
.version, update the CHANGELOG, commit these, and tag the commit asv<version>:$ npm run releaseIf all is well this new
versionshould be identical to your intended<version>:$ jq ".version == \"${version}\"" package.jsonIf this is not the case, then either your assumptions about what changed are wrong, or (at least) one of your commits did not adhere to the Commit Message Format Discipline; Abort the release, and sort it out first.
Publish
To NPM
$ npm publishOn GitHub
git push --follow-tags --allClick the
Draft a new releasebutton;Select the appropriate
v<version>tag from the dropdown menu;You could enter a title and some release notes here; at the very least include a link to the corresponding section in the CHANGELOG as:
[Change log](CHANGELOG.md# ... )Click the
Publish releasebutton;
ChangeLog
See CHANGELOG.
