incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Burke <jrbu...@gmail.com>
Subject Re: Work Items for 1.5.0 - unified JS
Date Wed, 08 Feb 2012 19:34:53 GMT
On Wed, Feb 8, 2012 at 6:53 AM, Patrick Mueller <pmuellr@gmail.com> 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

Mime
View raw message