tparisi / glam

GL and Markup

Home Page:http://www.glamjs.org/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

CommonJS build step

srounce opened this issue · comments

Really dig the project, I'm quite interested in contributing, but the build setup is really putting me off. Having to memorize what's available and when introduces unnecessarily lengthy (IMO) initial code reviews for potential contributors getting acquainted or those wanting to make small fixes.
Would you be open to using (Browserify)[http://browserify.org] & NPM?

@srounce are you talking about the build setup for the GLAM library itself? Or the web site?

Looking at some other issues it seems that you've considered using some sort of library for a build set. Browserify might be a good option. This'll also make it easy to publish to npm and be more attractive to people wanting to use it. One of the reasons that Three.js is popular is that they've integrated with npm and make it very easy to integrate with.

Node modules would be most welcome and may help ease the integration of vizi into glam #29

Hi all,

I'm hardly a build guru so I am very open to input here. If someone can suggest a scheme that would be great. FYI I build Vizi (the underlying engine that sits between GLAM and Three.js) using Google Closure and shell scripts. That's not perfect either. But I like Closure because it checks dependencies and whatnot.

I would love to hear suggestions not only on a tool but a whole build process. Browserify is intriguing because at some point I was thinking of creating an isomorphic GLAM library that can run on client or server-side!

The easiest way that I can think of is with Browserify and the uglify transform. Then the dependency management is trivial via npm

You might want to read up on CommonJS To see how you'd change the way you split stuff up. (Rather than concatonating, you require() files.)

Closure should be relatively easy to handle in a build system; gulp is suggested in #33 and would likely be able to leverage gulp-closure-compiler.

Hoestly, in my experience the closer compiler step just spooked people away from contributing because they'd need to set up Java to build stuff, which might not always be wanted. With browserify, or even with gulp, it's just node and they wouldn't even need to install global tools for them.

@RangerMauve I'm leaning that way... please suggest a node-based scheme that I can go research and get comfortable with.

@tparisi I'd suggest reading the browserify handbook and then maybe taking a look at some library source code to see how other people are structuring things.

Then you might want to try making a small module of your own to publish to npm, just to get the hang of the flow. If you have any specific questions, feel free to email me (it's on my github profile).

Fantastic! Thanks to all for the input...

I will dig into this very soon, as in later this week. It's fundamental and has to get done soon so there's no ducking it on my end; just a matter of ordering over the next week or so.

Yeah, and you'll definitely see the benefits once you get the hang of it. Thanks to npm we have a huge amount of modules already out there so you can get a lot more done a lot faster, and with browserify you don't have to worry about client-side dependencies.

Apols, late reply (hopefully not too late), I can get the basics ready in a branch sometime this midweek if that helps?

Dup of #33 let's track there.