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

+1

Your index.js example is exactly how we are planning to do concatenation. This will allow you to stitch together JS files or create compiled client-side templates by naming them person.js.jade. I first saw this approach with http://github.com/HenrikJoreteg/templatizer.

Stylus, SCSS, and LESS, all give you the ability to import other stylesheets so I don't see the need for this convention (don't see a good reason not to do it either).

IMHO you should never see the www directory unless you really must (such as exporting for Apache Cordova). Harp already behaves this way. Just fire up the server.

|- public/
|   |- application.js/         <-- one big-ass JS file that gets served by harp (not yet implemented)
|   |  |- person.js.jade       <-- jade template compiled to JS. perfect for Backbone templating.
|   |  |- jquery.js            <-- regular JS gets merged in (nothing special happening here).
|   |  '- stuff.coffee         <-- gets precompiled to JS and merged in.
|   |
|   |- css/ 
|   |  |- topcoat.styl         <-- becomes css/topcoat.css (this works today, using Stylus)
|   |  |- _overrides.styl
|   |  |- _froms.styl
|   |  '- _nav.styl
|   |
|   |- index.md
|   '- _layout.jade
|
|- harp.json
` README.md

www is already an artifact. Drop the src directory or rename to public.

@sintaxi ya concat stuff I knew you guys had coming but what about browserify? (thusly we could build similar w/ topcoatify)

How do you control the order of files that get merged?

Linking with an issue I opened that is similar sintaxi/harp#127

@danielgtaylor thanks, how would order matter if the purpose is to have the scripts concatenated? I figure it wouldn't. Am I missing something?

@sintaxi, here's a simple example if the files are just concatenated in lexicographical order:

main.js/foo.coffee

console.log(add 1, 2)

main.js/utils.coffee

add = (left, right) ->
    left + right

Output from Harp: main.js

console.log(add(1, 2));              <----- Reference error: no function add exists

var add = function (left, right) {
    return left + right;
}

Because f comes before u the order of the files is wrong and we get an error. Browserify or other module-related stuff can help, but I'd be wary of pushing browserify on everyone. You could also name your files starting with a number, for example, but then you lose lexicographical order in your text editor/file manager. An alternative implementation that's fairly straightforward would be to support pre-processing the file looking for special comments, e.g. something like this:

main.coffee

#= include _utils.coffee

console.log(add 1, 2)

The special comment would be replaced with the contents of _utils.coffee and then the entire file can be compiled to javascript. Note: I changed the name of utils.coffee to _utils.coffee in this case since we don't want a utils.js in the final output.

I'm not saying the special comment is the best approach, just trying to provide an alternative that could work. I'd love to hear your thoughts on all this.

I think a manifest file would be a slightly better way to handle this as well. It's very similar in more established static site generators and is very common place in the Ruby world. Middleman has a nice implementation of this, it just uses Sprockets on the backend (https://github.com/sstephenson/sprockets)

While a "smart directory" would be very nice and may work for the majority of use cases, I've often found myself having to load my javascript files in a specific order.

All of that said, there are certainly utilities like GruntJS that can handle more specific needs so I'm sure everyone will use the tools that best suit them. Either way a step in this direction would be a nice addition.

Just my 0.02.

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