On Tue, Feb 7, 2012 at 09:05, Filip Maj <[email protected]> wrote: > The exact repo I'll be going over is located at ... blah blah blah >
Perfect. Some thoughts on module usage in callback-js. * In general, I'm very happy with the current shape. Which is: 1) our modules are authored in CJS style (no AMD wrapper) 2) an AMD wrapper is added at build time, where the relevant modules are concatenated into platform-specific all-in-one .js files. * currently almond [1] is being used as the AMD runtime. Couple of problems with that: - almond currently doesn't throw exceptions when undefined modules are require()'d. This is a very bad thing. There's currently a bug open on this at GitHub [2], which you should chime in on, as James is for some reason reticent about fixing it. - while almond supports both require(moduleName) and define(moduleId, moduleFactory), which are the two APIs we seem to be making use of, it also supports the overloaded async require() forms, as well as the define() forms that allow you to specify pre-reqs. It also supports "plugins". All of that "also" stuff, in my book, is not good, and I don't want to make it available to our users by default. Nor do I want our code to make use of it. Those "also"s are not supported in natively in node, for instance, making any module you write that depends on them, a module that will not run naturally in node. * given the above, I'd prefer that we own our own AMD-lite runtime. Eventually, I'd like to have node's "node_modules" dynamic runtime module look up as well, which I'm not sure we will be able to find in a minimalistic AMD-lite runtime. weinre has been using modjewel [3] forever as 3rd party code, and it's being added directly to weinre in an upcoming commit [4]. Turns out I know the author, and although he's kind of a prick, I think I can convince him to add the node_modules lookup bit. :-) * "make the AMD runtime available to our users" - from the note above. Turns out, we've exposed at least "requirejs", "require", and "define" in the platform-specific all-in-one files. That's great and that's horrible. I would love to offer our users an AMD-lite capability. But for some folks, like folks using Dojo, this is probably going to be problematic. I see three possible use cases: 1) expose our AMD-lite to folks 2) don't expose our AMD-lite, by just wrapping the existing platform-specific all-in-one .js files in another function wrapper 3) allow folks to supply their own AMD-lite compatible runtime, like requirejs or dojo. Maybe the best thing to do is to is 1), and then provide a command-line mechanism for folks to wrapper it for 2), or use an alt-AMD-lite runtime 3). * not entirely clear to me whether we are intending that folks can use require(someCordovaComponent) in their own code or not. Presumably there is some VERY close relationship between the things exposed via some path through "window" and the module exports you get back from a require(someCordovaComponent), and so this is "just" adding some documentation, and then adding some test cases to ensure the same objects are available both ways. * Has anyone thought about making all this work via npm (or equivalent) somehow? This would mean that every "top-level" Cordova component would actually be an npm package, with an associated package.json file. I guess the story would be that you could "npm install foo" and "npm remove" packages all day long, and arrange to "rebuild" the platform=specific all-in-one .js file. For me, I could imagine building my app as a set of packages as well (well, one "main" package), and treat Cordova components no differently than I treat underscore, backbone, etc (eg, as AMD-lite-able modules). [[note: I'm not actually suggesting that we publish Cordova components at npmjs.org; just yet :-) ]] * we should provide debug versions of the all-in-one .js files - see [5] for more info; Browserify is making use of the same technique (IIRC). [1] https://github.com/jrburke/almond [2] https://github.com/jrburke/almond/issues/8 [3] https://github.com/pmuellr/modjewel [4] https://github.com/pmuellr/incubator-cordova-weinre/blob/issue-83/weinre.web/modjewel.js [5] http://pmuellr.blogspot.com/2011/11/debugging-concatenated-javascript-files.html -- Patrick Mueller http://muellerware.org
