After building more and more node.js modules based on code generated by gitemplate, I ended up with a lot of nearly identical
Gruntfile.js files. Scaffolding git repositories saved time upfront, but maintaining grunt configuration was time-consuming.
audit-shelljs assisted automated maintenance when possible, but the underlying problem was still duplicate
Instead of holding all config in a large
Gruntfile.js and/or using
require to split some logic chunks into one-offs,
grunt-horde shrinks a
Gruntfile.js to something like:
loot call accepts a directory path or local NPM package name, then recursively merges in the module’s key/value payload.
Inside a module directory, file name conventions follow
grunt method names, ex.
initConfig/jshint.js file adds a
middleware property to the final
jshint section applied to
module.exports function discovered by
grunt as an argument and also context methods for reading, writing and removing keys:
this.kill. The methods are also available on the object produced by
Gruntfile.js. And each supports deep object-path strings like
loot allows developers to compose modules based on inheritance. The first module imported by
loot could seed a
jshint section with patterns very common in dependent projects, then more granular modules could update/remove them as needed. Several module intents:
All supported sections —
registerMultiTask — are similarly composable.
To help debug compositions,
grunt-horde emits several events on the
grunt.event bus for tracing the source of config mutations.
grunt-horde in conjure to load several modules and set some config keys manually.
initConfigkeys to project-specific values. For example, grunt evaluates
<%= projName %>as