My reaction to this was "why are we requiring that jade be an immediate dependency of the user project?" and was then "Oh I bet he's copying how I did it for handlebars", and I was right.

So, thoughts.

0. That `locateHandlebars` methods is one of the first things we added to Lineman and is pretty outdated now relative to other features / techniques for doing stuff, so I'm not married to it (if I were you I'd have followed the pattern just like you did though). Handlebars is also slightly different because no matter how you slice it, there's a vendored runtime JS library needed to use it that the user also has to add.

1. This approach means that users will have to install the jade module before they can use it; if we require that then it almost seems preferable to just require they install a lineman-plugin, because as it turns out this PR adds `grunt-contrib-jade` which itself install jade.

2. When I raised the idea of plugin-ifying it, @jayharris raised the good point that it means the pages task would be a little bit bothersome to pull apart and I agree. Additionally, because of our need to call `compile()` on jade itself it means that such a plugin would need to either depend on jade or sneakily go and snatch it from grunt-contrib-jade. The former sucks because it may not be deduped by npm and may be a different version of jade than what the task is loading (which would be confusing). The latter sucks because node doesn't give us a proper way to do that and the implementation is a little yucky.

Am I making any sense? @davemo / @jasonkarns ?