incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Mueller <>
Subject proposed common-js file moves/renames for post-1.5
Date Fri, 24 Feb 2012 04:07:07 GMT
I finally got a chance to start looking at the common-js bits this week.

One thing that's had me confused, is figuring out how all the files get
combined into the platform-specific single files.  It's not real obvious
from looking at the files, or the resulting output.  Looking at the
packager.js script gives you the recipe, but it's nice to see the whole
thing laid out.  Which I couldn't see.

I instrumented packager.js to dump the module names and original file names
of the source.  The result is here:

(neat that you can enabled a wiki on your cloned GitHub repos!)

On the left is the module id, the right is the original file name.

Based on that, came up with a few thoughts on a clearer organization of the
.js files, here:

It seems to me like we should be able to do a little re-org of the files,
with changes to packager.js, to make things a little more obvious.  All
without changing any of the actual code - just the file names/directories,
and packager.js


- rename `lib` to `cordova`, since that's the top level module bit in our

- move the platform-specific modules out of `lib`, into a new top-level
directory named `platform`, which has subdirectories for each platform, and
then cordova/blah/... directories for any additional files for the
platform, including potentially overlaid files

- there are also plain ol' scripts like `require.js` which should be
separate from the modules, in say a top-level `scripts` directory

All that would, I think, be a little clearer.  And would likely simplify
packager.js.  Would also easily allow you to 'overlay' a platform-specific
file over a common one, if you wanted.

If we had a 'portable' version of `cordova/exec.js` and
`cordova/platform.js`, that existed in the portable directory but was
always overwritten by platform builds, then the `cordova` directory could
actually be the source for a "mock" version of Cordova - that you could
load in a desktop browser, say.  In theory, it would be easy to ingest this
kind of directory structure in an AMD environment as well.

I would also really like to create a subdirectory-per-plugin in the
`plugins` directory, but this will affect other code, since those modules
names will be changing.  It's a step in the direction of "all our plugins
are just like any other plugins".  Due to the code changes required,
wouldn't be including this in the first refactor.

I was thinking this might be something we could do post-1.5.  Thought I'd
go ahead and start playing with it, see how it feels.  Anyone have
thoughts, or know of any reason why this wouldn't work, or be more
confusing than the current layout?

Patrick Mueller

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