Build System about glam HOT 54 OPEN

Maybe look at gulp

from glam.

As per #15, would you be interested in a PR for having this?

from glam.

@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

from glam.

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.

from glam.

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.

from glam.

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.

from glam.

FYI I'm getting a CloudFlare fail on that URL right now...

from glam.

The guide? Here's another one that goes over most of the same stuff.

from glam.

OK that one works.

from glam.

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.

from glam.

Could we possibly get away with assuming those are globals?

from glam.

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.

from glam.

Alternately if we absolutely must use some globals, it'd be possible with browserify-global-shim

from glam.

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.

from glam.

OK I need a day to clean some things up:

1. Oculus files will go into the GLAM core
2. 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)
3. Old Three.js can be gone

Stay tuned.

from glam.

The parsecss stuff could probably be replaced with something available on npm pretty easily.

from glam.

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.

from glam.

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?

from glam.

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.

from glam.

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?

from glam.

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 install to install the dependencies and dev dependencies
• run wither npm run build or npm run watch to have the project built
• make changes
• ???
• Profit!

from glam.

Sounds reasonable and I'm delighted to be the guinea pig for it. LMK!

from glam.

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.

from glam.

Yeah the deps work in Closure already, for whatever that's worth. I await with bated breath!

from glam.

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 ... */}

from glam.

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)

from glam.

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.

from glam.

As long as the API surface stays the same, I'm down with it.

from glam.

Oh and what happens with debugging... you'll see the generated source? Or use source maps?

from glam.

Yeah, browserify supports source maps.

from glam.

kewl any other big discussion items to cover? it sounds like you're on it.

from glam.

Well, I'll post here if more stuff comes up.

from glam.

Here's the progress so far with the src/animations folder. This is more or less how everything else will look like.

https://github.com/RangerMauve/glam/commit/81f04dc3f9ed15e0ae10a8fed12cd908de3bb8bd

from glam.

Ok that looks awesome and non-invasive.

[another n00b question] Does does require() actually translate to something at runtime (like require.js does) or is that purely a build-time construct?

from glam.

With browserify it gets used at build time, and specifically it gets used to see what the dependency tree looks like by starting at some top-level file, and then following calls to require() all the way then. After its looked at all the requires, it essentially makes a map of path in fs : function(module,exports){ the module code here}

The module used to look up the dependencies is module-deps.

On of the cool things about browserify and a lot of modules made with npm, is that a lot of things are decoupled into small modules that do just one thing well, so there's a lot of potential for re-use.

Here's a small guide on how require() works.

from glam.

sweet... I love that this is forcing me to catch up with the modern way of doing things. much obliged!

from glam.

Yeah, and once you get used to it I guarantee you'll love it. Just having all of NPM at your disposal for any projects you work on makes things so much faster. :D

from glam.

I loves me some node, just haven't been using it for client stuff. Till now! :-)

from glam.

So, one question that comes to mind. Do all the internals need to be exposed publicly with the API? Or is there some subset that users of the library would actually ever use?

from glam.

This is a great question. There's no short answer. Here's an attempt at a medium-length one:

1. The intent is to provide an API that is as DOM-like as possible. e.g. document.createElement('cube'), cube.setAttribute('width') and so on. In that regard, it's a small API surface.
2. However, under the covers there is this engine, Vizi, that I have been working on for over two years. That is similar in design to Unity, in that it provides an entity/component model with a lot of power. At this point, I am not sure how much if any of this engine power will be surfaced to the programmer. There are two ends of this spectrum: 1) hide it all and just provide a DOM-like API and 2) expose it all and give developers a ton of expressive power. The eventual reality will probably lie in between, and if I had to guess now, closer to number 1.
3. A lot of the GLAM (nee Vizi) engine API is dedicated to adding ease of use to writing code for Three.js. If I can devise an API that is close to DOM but then exposes Three.js as the graphics layer for people writing extensions/custom GLAM components, I may be able to chuck (or reshape) most of what is in the Vizi layer right now.
4. I plan to migrate the code base to web components, because everybody seems to be headed in that direction and I am currently duplicating a lot of effort in the guts of the GLAM implementation. That will no doubt influence the design decisions around the API surface as we go forward.

That's the color commentary. Bottom line, it won't be all the internals but it might be some. Does that help?

from glam.

Yeah makes sense. But in a more short-term view. Should I be exporting every single object when people require glam at the moment, or would it be OK to just have .ready(), .setFullScreen(), etc. Or should I just leave that for you to take care of once all the other parts are requiring each other?

from glam.

There are maybe a couple of other entry points at most that are used by the current GLAM examples. Just export those. Search recursively for glam. in the examples/ and demos/ folders and that will tell you. I think there are only one or two.

I will take care of everything else. Actually I think it's a good thing that we do it this way because that will force me to very carefully reevaluate the whole API before publishing the interface publicly.

from glam.

Kay, I'm, kind of intimidated by how big the dom folder is. Would you be interested in giving it a shot based on the other folders I've converted? Also, do you think it'd make sense for me to push this to a new branch here so that others could join in on the action?

from glam.

Send me a link to what you've got and I'll look.

This should really be in a branch. I'm currently working in the alpha 2 VR branch but feel free to make a new one

from glam.

Well, here's a good example of where things have changed. As for the new branch, do you think you could add browserify-build so I can send a PR to it?

from glam.

what is browserify-build ?

from glam.

I meant, adding a branch called browserify-build to the repo so that I can send a PR specifically to it and not interfere with the other branches. I was thinking it'd be a descriptive name for what we're trying to do with the code.

from glam.

Got it. Thanks for clarifying.

I'll make a branch off master... just give me a few to figure out whether I should merge Alpha 2 back into it first. Stay tuned.

from glam.

kk!

from glam.

I'm tidying up some starter doc files (beginnings of tech documentation). Give me a few hours and I'll publish that branch for you.

from glam.

@RangerMauve hey that branch is published... I branched off master which also has the latest Alpha 2 merged to prevent too much drift. Please have it, send me a PR when it's far enough along. At that point I can take a shot at dealing with the DOM folder and anything else that was giving you trouble. Much appreciated!

from glam.

I've added PR #48 with the changes. I'll probably be continuing with some of the other folders later today, too. I'll make a new PR for the other changes.

from glam.

@RangerMauve quick update, I just finished up my Kickstarter project goals work. Now I can get back to this. It will be part of the first true Beta milestone so it's in the near future. Stay tuned!

from glam.

Awesome!

from glam.