Client-lib controls bundling

[rvagg]

From #160:

Allow for replacement of CommonJS with alternative bundling techniques: I don't think there is a ticket for this but the idea here is that there is currently a strict link with ender-js as the "client lib" which manages CommonJS bundling plus adds the $() DOM collection stuff. CommonJS bundling is also hardwired into Ender, particularly 0.8 code. What I'd like to do is shift all of the CommonJS stuff out of the CLI and into the client lib and then make it possible to switch out the client lib with another that may bundle things differently; AMD perhaps.

We're already part way there now in 1.0-wip as it accepts a --client-lib arg and we have templates doing a lot of the bundling. The next step would be to push the templates into the client lib so a different client lib could supply its own templates.

A lot of this is in my head; if anyone wants details then ping me and I might be able to document this a bit more. I imagine implementation will involve a bit of experimentation!

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[amccollum]

Ok, so I wanted to give a progress update on my work on this. I pushed some code today that implements a lot of these mechanics, but also highlights some potential issues. There three relevant checkins are here:

• Ender
• ender-js
• ender-commonjs

The main user-facing change to Ender is basically to allow the user to specify a --module-lib option in addition to the --client-lib option. This is a temporary change, since I think the better longterm solution is to have a more plugin-oriented architecture.

The internals of Ender change quite a bit. First, is that there can be multiple root modules, which are now referred to as bare modules, and are indicated by a ender->bare key with a value of true in the package.json file. These packages are included without the standard module-wrapping that is done to other modules.

The second big change is moving more of Ender's semantics to runtime rather than compile time. This is done by creating a new JS class for modules which is implemented in ender-commonjs. This library also handles executing the bridge code and exporting any modules that are expose when in "sandboxed" mode.

There are two main reasons for this change to more of the work happening at runtime. First, it makes handling modules split across multiple files easier. The module object can include more intelligence about paths and require methods. Also, by defining all the modules first, the ordering of packages becomes irrelevant (dependencies don't necessarily need to come before their dependents). The second reason is that it becomes easier to implement other module formats. If the runtime library has more flexibility, there aren't as many constraints on how the build file is organized.

The main downside is an increase in final code size, but I think this is generally pretty negligible, overall.

Also, as part of this change, I've simplified the internal package objects, and given more control to the build assembly code. However, due to more functionality being moved to runtime, the templates actually end up simpler, as you'll see. I also made the choice that the assembly plugins should be able to choose their own templating strategies.

There are still bugs and small things missing that I'm working on, but I wanted to share the code now to see if there are high level comments on this direction and the overall implementation strategy I've taken so far.