grunt-coffee-jshint
v2.0.1
Published
grunt wrapper for coffee-jshint
Downloads
35
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-dev
Once 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 install
This 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 ./.gitmessage
Release
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 release
If all is well this new
version
should be identical to your intended<version>
:$ jq ".version == \"${version}\"" package.json
If 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 publish
On GitHub
git push --follow-tags --all
Click the
Draft a new release
button;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 release
button;
ChangeLog
See CHANGELOG.