Add support for browserify

[michael-lawrence]

First off, I have to say this looks amazing! The only thing I think it's really lacking is client-side JavaScript compilation and minification. I think browserify would be a match made in heaven! Any chance that we might see support for browserify added? Thanks!

[kennethormandy]

Hey @michael-lawrence,

JavaScript compression is planned: #54

I believe there’s a plan for compilation that wouldn’t involve Browserify. But just to make sure I understand the use case, you have a bunch of JavaScript files that you’d like reference using a single script tag?

[michael-lawrence]

@kennethormandy Correct. The thing that makes browserify great is that it uses the CommonJS spec and npm modules. This makes it pretty easy to share code/modules between the server and client. Also, it allows you to specify a transform module that allows for some pretty cool stuff like precompiling handlebars or jade templates and bundling those templates in your single .js file.

[kevinsimper]

That would be cool to have in Harpjs, but how would you mark the file that it should be browserify?

main.bify would become main.js?

[michael-lawrence]

You could just add a configuration option in the root harp.json. Something like browserify: ['app.js', 'main.js']. That way you don't have to have any special made up extensions. Alternately, you could do something like main.bundle.js and that could become main.js, so you just watch for .bundle.js files (or .bify.js files).

[kevinsimper]

I like the idea of that, if the file name features '.bundle.', it will be browerify.

[sintaxi]

I like the idea of adding browserify support. Esp if it can be achieved through a convention rather than through configuration. We'll keep this issue open for exploring this feature.

[kevinsimper]

I can see that assets is processed with the module terraform which is broke out of Harpjs.

If you wanted to do it, how would you go around and implement browserify?

[sintaxi]

@kevinsimper great to hear you want to chip in. I think browserify support is definitely worth exploring.

I would start by proposing a design that can be added to the Harp Spec for how browserify should work. My suggestion would be to put that in a gist or some place where we can iterate on the design.

Once we have a design that we feel aligns with the philosophy of the project then the next step would be to put this in a milestone and get you familiar with the terraform codebase. I would be happy to give you a walk through if you like. We then write some tests and come up with a plan of attack with the implementation.

If you have any other questions on how to move forward or want clarification on the design goals, come find me on #harp (irc.freenode.net).

[zeke]

Reviving this thread. @kevinsimper did you make any progress on this? I'm happy to help out if I can.

[zeke]

@sintaxi's above link to the spec is outdated. It now resides at spec.harp.io

[kennethormandy]

@zeke Fixed that, thanks.

[ncammarata]

Would also love to see this. Using Gulp now to get around not having it in Harp.

[kevinsimper]

I found a simpler solution and create a boilerplate, which can easily be used by saying harp init myblog -b kevinsimper/harp-browserify.

https://github.com/kevinsimper/harp-browserify

[zeke]

@kevinsimper this is a great interim option in the absence of first-class browserify support in Harp. Nice and minimal. Thanks for sharing.

[Prinzhorn]

Do we even need a configuration or convention for this? Can't we serve all JavaScript through browserify? If the file doesn't contain any require statements, then it will just serve it (with some boilerplate). If it does, it resolves them. In both cases you only need to reference a single file, e.g. (main.js) in your HTML.

Or maybe add a flag to harp server and harp compile to enable/disable browserify. This way I could just throw in my modules and require them from my main.js and it just works. Oh well, this might be against the philosophy of harp. So maybe we should really just use a special name like *.require.js or *.bundle.js.

[sintaxi]

@Prinzhorn indeed. we will have to figure out how this should work. I think you just described the optimal scenario. Thats what I'm hoping we can achieve. it should work identically with coffee-script.

[Prinzhorn]

Following up my comment on live reload (https://github.com/sintaxi/harp/issues/80#issuecomment-58925661) I'm now doing this

watchify index.js -o bundle.js

in combination with

browser-sync start --proxy 'localhost:9000' --files 'bundle.js'

and I'm happy with it :)

I'm not saying integrating it into harp would be a bad thing, but this way I know exactly what everything is doing.

[amitkeret]

+1 for @Prinzhorn's comment. I love not having to compile files for harp, would be even better if I don't need to package!

It's been almost a year... any progress?

[dgautsch]

Reviving this from the dead, has there been any movement on this feature? Or does this has to be implemented in terraform?

EDIT: I see terraform has an open request for this https://github.com/sintaxi/terraform/pull/97

[howardroark]

I would very much like to see it happen.

[DubaniWarrior]

trying to revive it in 2018. Has any progress being made on that?

[sintaxi]

This has been implemented but not announced. Add a bundle.cjs file to the root of your project and it will create a bundle.js file. Let me know how it goes.

[DubaniWarrior]

does it work with harp being install globally. because It doesn't seem to work.