standardSetup
sets up everything this project provides with the defaults.
An easy one-stop shop.
standardDefault
installs a 'default' grunt handler (what runs when you just type
'grunt' on the command line) which does what you likely want it to do. You can get
access to the list of tasks with the defaultTasks
key.
modifiedInLast
allows you to limit the scope of any participating task's target
files to the files modified in the last X minutes. X is defined by supplying the
'partial' option on the command line. For example:
grunt watch:doc --partial=2
loadLocalNpm
gets around the limitation in grunt.loadNpmTasks
- that it always
pulls locally-installed modules. The whole point of this project is to take the
difficulty out of using all of these grunt plugins. This method ensures that
any project using 'thehelp-project' needs only add 'thehelp-project' as a dependency,
not the various grunt plugins.
registerWatch
sets up watch with no tasks, ready for other registration
functions to add them.
registerJsonLint
sets up the jsonlint
task to ensure JSON is well-formed (giving
far better error messages than a basic JSON.parse
). Set up by default to lint every
*.json file in the root directory of the project.
registerEnv
sets up the env
task to populate environment variables. By default it
uses data from 'env.json' in the current working directory (the root of your project).
registerClean
deletes directories as specified in options, or in
three default directories: 'dist,' 'tmp,' and 'public.
registerTest
does everything required to get a number of test-related
tasks in place, including the ability to run unit tests whenever a test
or source file is changed.
Several options are supported by this set of tasks:
blanket
will automatically requiredNote: the 'partial' option will force you to save the test files themselves to get tests to run, since that's the set of files supplied to mocha. Even if we watch all files, we still provide only the set of test-containing files to mocha.
registerStaticAnalysis
sets up two tasks: 'jshint' and 'complexity.' It also sets up the
ability to run both of these whenever any javascript file changes in tne project. Within
the 'jshint' task we create two sub-tasks: 'src' and 'test.' Test has a
frequently-encountered rule turned off.
Note: Participates in the 'partial' filtration option.
registerStyle
sets up one task: 'jscs' with a default set of rules. You can
specify your path to a JSON config file with the jscsrc
key.
Check the jscs readme for more information on what it does.
Note: Participates in the 'partial' filtration option.
registerDoc
uses groc
to process markdown comments in source files into
nice documentation files in HTML. It also uses a custom-developed
fix-groc-stylesheet
task to do better
than the default groc stylesheet, recopied on every run.
Note: Participates in the 'partial' filtration option. Highly recommended when making many edits to one file, as groc runs take a long time. However, note that 'behavior.js', which contains site navigation javascript data, will generated as if only the files passed to it are available. You'll need to do a final complete run to restore your complete 'behavior.js.'
registerCopy
uses the grunt-contrib-copy
task to copy files. You can provide your
set of file copies file by file:
registerCopy({
files: {
'target': 'source',
'dist/mocha.css': 'lib/vendor/mocha.css',
'dist/harness.js': 'src/client/harness.js'
}
})
Or in wildcard groups like this:
registerCopy({
files: [{
expand: true,
cwd: path.join('node_modules', module, 'dist'),
src: ['*.js'],
dest: 'lib/vendor'
}]
})
More information on configuring file lists. If no options are specified, this method will simply pull in the copy task for your customization.
registerShell
makes the 'shell' task available if no options are required. Here's an
example of how to add bower install
to your grunt tasks:
registerShell({
'bower-install': {
command: 'bower install',
options: {
failOnError: true
}
}
})
GruntConfig
Configures grunt-based automation for the project. Just create an instance of this class, passing in
grunt
, then callstandardSetup()
.Registration for specific scenario is in each of the
registerXXX()
methods below. It's split out this way to keep related configuration in the same place, since most scenarios have config points in different parts of the config tree: