Instantly share code, notes, and snippets.

Embed
What would you like to do?
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
|- 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
@sintaxi

This comment has been minimized.

Show comment
Hide comment
@sintaxi

sintaxi Oct 12, 2013

+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 commented Oct 12, 2013

+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.

@brianleroux

This comment has been minimized.

Show comment
Hide comment
@brianleroux

brianleroux Oct 13, 2013

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

Owner

brianleroux commented Oct 13, 2013

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

@danielgtaylor

This comment has been minimized.

Show comment
Hide comment
@danielgtaylor

danielgtaylor Oct 18, 2013

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

danielgtaylor commented Oct 18, 2013

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

@danielgtaylor

This comment has been minimized.

Show comment
Hide comment
@danielgtaylor

danielgtaylor Oct 18, 2013

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

danielgtaylor commented Oct 18, 2013

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

@sintaxi

This comment has been minimized.

Show comment
Hide comment
@sintaxi

sintaxi Oct 19, 2013

@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 commented Oct 19, 2013

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

@danielgtaylor

This comment has been minimized.

Show comment
Hide comment
@danielgtaylor

danielgtaylor Oct 21, 2013

@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.

danielgtaylor commented Oct 21, 2013

@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.

@conraddecker

This comment has been minimized.

Show comment
Hide comment
@conraddecker

conraddecker Oct 22, 2013

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.

conraddecker commented Oct 22, 2013

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.

@edrex

This comment has been minimized.

Show comment
Hide comment
@edrex

edrex Oct 29, 2013

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.

edrex commented Oct 29, 2013

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.

@edrex

This comment has been minimized.

Show comment
Hide comment
@edrex

edrex Oct 29, 2013

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 :)

edrex commented Oct 29, 2013

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 :)

@danielgtaylor

This comment has been minimized.

Show comment
Hide comment
@danielgtaylor

danielgtaylor Nov 1, 2013

@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 😦

danielgtaylor commented Nov 1, 2013

@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 😦

@howardroark

This comment has been minimized.

Show comment
Hide comment
@howardroark

howardroark Jul 3, 2015

@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.

howardroark commented Jul 3, 2015

@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.

@og2t

This comment has been minimized.

Show comment
Hide comment
@og2t

og2t commented Oct 2, 2015

+1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment