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: https://github.com/pmuellr/incubator-cordova-js/wiki/cordova-js-file-to-module-map (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: https://github.com/pmuellr/incubator-cordova-js/wiki/cordova-js-file-location-refactoring 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 Changes: - rename `lib` to `cordova`, since that's the top level module bit in our modules - 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 http://muellerware.org
