incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Mueller <pmue...@gmail.com>
Subject Re: Work Items for 1.5.0 - unified JS
Date Wed, 08 Feb 2012 14:53:27 GMT
On Tue, Feb 7, 2012 at 09:05, Filip Maj <fil@adobe.com> 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message