incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Mueller <>
Subject Re: CB-280 - Improve layout of cordova-js scripts
Date Wed, 21 Mar 2012 21:42:31 GMT
On Wed, Mar 21, 2012 at 16:55, Brian LeRoux <> wrote:

> I don't mind this shed but I'm wondering what the purpose of
> lib-platforms/blackberry/cordova part?
> why not just lib-platforms/blackberry/ ??
> also, and again just touring around the shed, do we plan to ditch
> lib-platforms for lib/platforms after the merge is complete?

Good questions.  I'm not married to the current split, just seemed like the
most consistent way of doing it, once I got around to writing the code.
 The reason for the unwieldy "lib-platforms/blackberry/cordova" bit is
that, again, I can look at any file name and see what the actual module is,
by look 'up' the path to the cordova part.

But it seems a bit much.

I think one thing that might make sense is to just drop 'cordova'
everywhere in these trees.  One thing I'd like to eventually do is to use
"relative" module id's everywhere, and then in that case, you'd NEVER see a
require() with a 'cordova' in it anyway (except for 'root' require()s), at
least in our own modules.

There's one minor hitch with that, and that is that we have a 'cordova'
module, and then modules like 'cordova/builder'.  To make this work today,
the common tree needs a 'cordova' directory, along with a cordova.js
sitting right next to that directory.  Slightly weird.  Node has a
convention that says: if you're looking for module x/y/z, but can't find
x/y/z.js, look for x/y/z/index.js.  If we also adopted this (not difficult
to implement), then we'd move the code in lib-common/cordova.js into
lib-common/cordova/index.js.  Then we can cleanly kill all the 'cordova'
directories, because there won't be anything else IN those directories, but
the cordova subdirectory.

So, some thoughts, assuming removal of the 'cordova' directories, given the


1) flatten to /lib:


2) additional flattening of removing 'platform'



2) seems like the best to me, as flat as we can get, but has one issue, in
that our 'special' names (currently just 'common' and 'scripts') are in the
same 'namespace' as platforms.  Hope noone comes up with an OS called
'common' or 'scripts'  :-)  Prolly not a big problem.

You can modify the script 'build/' to play with how things
are split up.

Patrick Mueller

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