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: