On Wed, Feb 8, 2012 at 6:53 AM, Patrick Mueller <[email protected]> wrote: > * 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.
The bug is still open. It will restrict the ways in with almond may be used, but I am open to narrowing that focus. So feedback in that bug is encouraged. > - 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. Node's require is not suitable for use in the browser, in particular the lack of a callback require really hurts, and loader plugins help deal with the async nature of resources loading in the browser.The ability to inline text templates via the text plugin in builds is really handy. That said, I'm supportive of what you say below about making your own AMD-lite shim. It is good to have specific ones tailored to specific design goals. > * 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. :-) I recently added an "npmrel" task to volo: https://github.com/volojs/volo/blob/master/volo/npmrel/doc.md You can try it following the volo details here: https://github.com/volojs/volo (use the master dist/volo.js) The goal is to allow the consumption of an NPM-installed package that has nested node_modules dependencies in an AMD loader. The end result is that it should allow usage of that package in any basic AMD loader or shim, like almond, without requiring some new configuration options or loader logic. So even if you make your own AMD-lite, perhaps the above command can help massage any npm/node package into something that can be used directly. Insert the standard disclaimer: not all node/npm code is suitable for use in the browser, you may need to contact the original code author for slight modifications, since they may not have intended browser usage. Also, npmrel is still very new. I'm sure it needs exposure to more real world code, but I'm willing to do bug fixes for it. > * "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). Unfortunately I have not looked at the latest cordova code, but I do plan on making cordova-based apps that use an AMD loader. In particular ones that can use an 'env' plugin to load the right adapters/plugins for android vs ios vs whatever. So I am happy to test out any solution that allows me to run my own AMD shim (or full loader) that at least allows for loader plugins. > * 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 :-) ]] The aforementioned volo can install code from github, or any url that is to a tar.gz file, and allows setup of projects that have a certain build style via project templates on github. If the project implements a package.json 'amd' property, then any project dependencies added to it can be converted to the wrapped style. Just mentioning it as a tool that may help build up phonegap projects, at least for ones that want a particular style. volo also allows installing new 'commands' for it, so for example, you could come up with a set of phonegap specific commands for it. The other plus is that it is designed to be delivered as a single file -- someone could take it, bundle a set of different default commands and deliver that JS file for others to use that has built in phonegap-specific functionality. I get lost in the amount of bugmail for this project, so I end up not checking this list that often. Maybe I need to do better filters. But always feel free to ping me to look at a thread/repo if it would be helpful. James
