On merges in the root, in our internal implementation it was under www, however this became problematic to devs understanding. It became far to easy for root level www code to end up in merges. We even named ours _platformOverrides to try and make it pretty explicit, but no one liked the mixing the peanut butter w/ the jelly. Thus the root level designation, which I like.
Option 2 doesn't kill me, however it does muddy the water a bit when deving purely in browser that www lives under a top level app, as app is Š dare I say nebulous. The benefit of the current set up is that while it might not be strictly just www, its simple. When some one starts they gravitate to www, and look around and then the readme and config are in context to where they will for the most partŠ. live, which is a good thing. mw On 3/22/13 6:15 PM, "Brian LeRoux" <b...@brian.io> wrote: >I'm ok with ./merges at the same level as ./www but the config.xml >inside of ./www bugs me too. I think having a root level ./www just >works well mentally in that its obvious whats there, what it does, and >who it effects. The ./merges folder is really just stuff that gets >added to ./www in the right cases so having at the same depth is ok >(for me). > >I get where you are coming from though. > >The real sticky bit is a config file hiding with the app >implementation. It seems like that would live at the root. The idea of >having it inside of ./www is a simple zip and rename of ./www would >result in an installable package...but logically with our tooling and >such that would be a build artifact that just lives in ./platforms >after we do our magic. > >=/ > > >On Fri, Mar 22, 2013 at 1:24 PM, Michal Mocny <mmo...@chromium.org> wrote: >> Paraphrasing our meeting notes today: >> >> * currently www/ has to have config.xml inside it, docs inside it, >>README >> etc >> * merges folder is already a sibling of www/ but its logically part of >>the >> app. >> * So, why not move everything that isn't the actual assets of the app >> itself out of www? >> * Option 1: move everything out into the root. >> * harder for git versioning your app, since cordova artifacts >> (platforms, plugins) are inside. >> * Option 2: make a new top level "app/" folder that holds merges/ and >>www/ >> and manifestes etc >> * then you can just clone/install an app into one location >> >> >> And I'll throw out a third option: Create an "apps" folder which can >>have >> any number of named apps, like plugins. >> >> >> I think (2) should be totally doable (just change some default paths in >>the >> tooling) and is a strict improvement (minus the hassle of moving your >>files >> around the first time for app devs). (3) I think is interesting, but >>is a >> bit of a departure. >> >> -Michal
