fantasizing about some future integrations. - bringing harp some awareness of smart directories to build concat/min into convention - browserify for harp would be sweet - topcoatify does not yet exist but increasingly we something like it should exist - next www can just 'disappear' as that it becomes a build artifact

harp-mod-request.md

|- node_modules/
|- src/
|   |
|   |- index.js/ <----------- uses browserify so anything in node_modules is game for require()
|   |  |- index.js
|   |  '- foo.coffee
|   |
|   |- index.css/ <---------- uses topcoatify so anything in node_modules is game. how import/etc works needs consideration
|   |  |- index.css
|   |  '- bar.styl
|   |
|   |- index.md
|   '- _layout.ejs
|
|- www/ <--------------------- everything in here is generated from above
|  |- index.js
|  |- index.html
|  '- index.css
|
|- package.json
'- readme.md

I think straight browserify combined with the leading _ convention would be ideal, since it follows the existing convention of using preprocessor-specific include mechanisms (Jade mixins, LESS) and is super simple to understand — just require("./_includes/my-include.js"). Appeal to orthogonality. Also bonus that it supports NPM packages.

Oops, realized Browserify requires included modules follow the Node.js module convention of assigning a public interface to module.exports, so wouldn't work with arbitrary JS. I'm a node-ecosystem n00b :)

@sintaxi, any updates on this feature? This is by far my biggest issue with Harp at the moment. If I have to write a separate build system for concatenating my scripts then I might as well not use Harp 😦

@sintaxi ... Any updates on this?

Having the ability to concatinate JS, set bower_components to copy only and ignore node_modules would allow me to win any conceivable argument for using Harp instead of Grunt or Gulp.

+1