add --amd option to generate ender.js as an AMD whole #158

Closed
wants to merge 2 commits into
from

Projects

None yet

3 participants

@jfromaniello

My goal with this change is to be able to build with enders a file that I can use later with require.js.

If I build like this:

ender build qwery bonzo bean domready --amd

It will generate an ender.js like this:

define(function(){
 var _ender = {};

 (function(){
   //all enders.
 }).call(_ender);

 return _ender.ender;
});

notice that this work pretty much like the "sandbox" option, in the sense that "provide" and all others are for that particular context.

Then, I can use this with require.js as follows:

define("/ender.js", function($){
 //do whatever...
});

Another thing to notice is that even if most of enders modules also register as AMD modules, they will not register in this case because most of the modules has a header like this:

  !function (name, context, definition) {
    if (typeof module !== 'undefined') module.exports = definition(name, context);
    else if (typeof define === 'function' && typeof define.amd  === 'object') define(definition);
    else context[name] = definition(name, context);
  }('bean', this, function (name, context) {

enders define module and module.exports. So, it will enter in the first if and the net result is that only ender is registered in the AMD register in this case which is perfect for my usecase.

What do you think?

thanks,

@rvagg
Member
rvagg commented Sep 6, 2012

@jfromaniello thanks for working on this. Unfortunately we're not going to be accepting any significant enhancements to the current master branch, work is well under way on 1.0-wip which is a totally new codebase.

AMD is something that I would be happy to see in 1.0 at some point but I rather not see it in the core as such; just like I'd like to see most of the CommonJS stuff moved out of the core. At the moment, Ender does CommonJS modules at the same time as doing the whole $() DOM wrapper stuff. I'd like to move it to doing those 2 things separately, CommonJS at the root and then the $() stuff on top of that. That will also mean that the CommonJS layer could be swapped out with AMD or other. The idea is to turn Ender into a slightly more agnostic build tool that is told what to do by the requested root module.

I can expand more on this if you're interested. I don't think I really want to do much AMD work myself as it's not something I'm particularly interested in but I'd be more than happy to help others' do that work and make Ender work for them.

First though, have a look at the 1.0-wip branch and see if you can get your head around it. Most of the interesting work is being done in templates now (I'd like to see the templates shifted out of the core, as per what I've said above) so it wouldn't be hard to adapt it to AMD.

@jfromaniello

Hi @rvagg thanks for taking the time to explain this. I agree with you, I will check the 1.0-wip branch and see if I can create some external template or so.

Ignore this pull request. I will keep the branch for a while in my fork since I had a project that depends on running, it has "ender": "git/jfromaniello/ender" in the package.json.

@amccollum
Contributor

I'm going to close this pull request for now. FWIW, with the new way packages are handled, and separating the module lib out from the ender-js it should be much easier to add support for AMD.

@amccollum amccollum closed this Feb 28, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment