tparisi
Build System
We need a real build system. Deal with this as part of the GLAM/Vizi integration. Related to #29
@RangerMauve howdy Ranger I would love it if you were to take this on... FYI I just merged the Vizi engine into the GLAM code base. It's all renamed GLAM, the idea is that it's the "glam engine." The whole mess uses the Closure-based build system from Vizi. I agree that we want to move this to node and NPM. So if you are interested in tearing into this, I would really appreciate it!
Note also that I am going to move this off the "Alpha 1" milestone and un-schedule it. I need to work on other high-priority items myself for the next week or so.
Let me know if you're still into working on this! Thanks
Yeah, I'm definitely interested. I'm not sure how many hours I can devote yet since I'm also working on another side project at the moment. But I'm definitely up for working on it.
Also, by the looks of it @srounce is also interested in working on this.
I was thinking of ignoring any gulp fanciness and just having browserify run with npm run from the get go.
The fewer tools the better! I hear you say "gulp fanciness" and I get scared.
I'm quite ignorant of web build systems. What I care most about is that it's (a) easy to install and use, assuming basic Node and NPM knowledge and (b) there's a way to have a continuous build task runner like grunt or whatever. I don't care what we pick. I have a strong preference for as Node-based as possible though.
Yeah, in terms of a CI I was thinking of using something like travis-ci which is pretty easy to set up.
Defining tasks should be easy enough by using the scripts property inside package.json. Here's a guide on how that works. Since NPM is a pretty core part of node, this would probably be the "Node way" of doing things.
Mind listing all the dependencies and links to where you got them from? I've found tween, threejs and jQuery, but I'm not sure about oculus, parsecss, and if vizi is an actual dependency or not.
No, then we wouldn't really be making use of commonJS to the fullest. Typically when you publish a module to npm, it is assumed that it is entirely self contained.
Let me go through all the external dependencies with a fine tooth comb. There are probably a few things to clean up, like Oculus, that should actually be part of the GLAM code base. There should also be no trace of Vizi in there going forward, anything that matter from that will now be named 'glam.*' Please stay tuned I am going to look at this right now.
OK I need a day to clean some things up:
- Oculus files will go into the GLAM core
- parsecss dependency will be removed; I need to de-jQuerify the whole thing. (Vizi was not dependent on it; the GLAM parsing only uses it in a couple of places)
- Old Three.js can be gone
Stay tuned.
I de-jQueryified parcess for now (just hacked the code) and pulled out the Ajax jQuery dependency. So, no jQuery required. This is all in the Alpha-2-VR branch. Next up: more cleanups.
Just got rid of other unused libs. Now the dependencies are only:
requestAnimationFrame three.js - library and extras files (files not built into the core) tween.js
They're still concatenated; would love to come up with a scheme to build this all using compilation/require-style techniques. But now it's in a form where an enterprising sort ( @RangerMauve !) could go at it with a PR. What do you say?
Perfect! I've got time today and tomorrow to work on it, too.
My plan is to do a dirty pass over everything and just get the dependencies over npm as well as linking all the files with requires, but after that we'll want to clean up the way different files require each other a bit.
All that; yeah thanks.
So just to be clear, a developer wishing to build will only need NPM? What will the work flow look like?
There will be a devDependency in the package.json for browserify, this will automatically create a binary in node_modules/browserify. Then, package.json will have a scripts property, and inside it'll define the command build which will just call browserify ./ -o build/glam.js, and I was thinking of having minifyify thrown in there to have the build-min command. Then we could also have watchify to have a watch command which will automatically watch for changes and rebuild.
But the flow for new devs would be
- clone the repo
- make sure node is installed
- run
npm installto install the dependencies and dev dependencies - run wither
npm run buildornpm run watchto have the project built - make changes
- ???
- Profit!
Since you have the goog.require and goog.provide stuff, it's easier for me to look up the dependencies, so this should be quicker than I though. Not sure on ETA yet, though.
Yeah the deps work in Closure already, for whatever that's worth. I await with bated breath!
You have a bunch of constructors being defined like
glam.SomeName = function(param){}
Would it be OK to convert them into regular named functions since that'll make it cleaner to export?
It'd look like
var util = require("util");
var SuperClass = require("../core/someSuperClass");
module.exports = SomeName;
util.inherits(SomeName,SuperClass);
function SomeName(params){ /* etc ... */}
OK here's where I display my ignorance: does that mean it all has to get run through browserify and that will somehow turn it into glam.SomeName?
It's a usage issue as in, I want to be able to say var sn = new glam.SomeName(params). Will that still work? If not, I need to know what the pattern would be (and there will be a ton of code to convert from using new)
Yeah, so each file will now export the thing that it's defining. At the top level in src, there will be index.js. It'll look something like:
module.exports = {
AnimationService: require("./animations/animationService"),
Interpolator: require("./animations/interpolator");
/* etc ... */
}
Then libraries using this will have code that looks like:
var glam = require("glam");
glam.AnimationService({whatever:"here"});
Internally, all the individual modules will just require the file that they want directly.
The API should stay exactly the same, it's just that the way it's all linked together will be a bit different from what you have with the closure compiler.
The compiled bundle will expose the global glam, if needed, and the bundle itself will actually be both AMD and CommonJS compatible as well. More details on how the bundle will be compiled are here.
Oh and what happens with debugging... you'll see the generated source? Or use source maps?