I can see the benefits, but they seem somewhat minor, so I'd prefer the compartmentalization of platform files. If I'm working on a specific platform, I can work in that platform's directory. Having the files spread out in a monolithic directory—especially once an app supports more than a couple of platforms—might get a little cumbersome.
On Mon, Mar 25, 2013 at 5:34 PM, Michael Brooks <mich...@michaelbrooks.ca>wrote: > Just like to provide an alternative suggestion to the merges/ directory and > here everyone's thoughts. > > While doing client work at Nitobi, each of our build scripts had similar > functionality to merging platform-specific web assets. Below, I'll describe > what I've experienced and make a suggestion on an improvement. > > 1. Separate Merges Directory > > app > |__ merges/ > | |__ android/ > |__ www/ > > In the above structure, the android/ directory is a mirror of the www/ > directory. When a file exists in the android/ directory, it will replace > the file in the www/. > > I believe this is how the merges/ directory in `cordova-cli` works. > > I've experienced two main problems with this approach: > > - difficult to keep track of what files are replaced, since you need to > cross-reference between directories > - too easy to start developing in the merges/android/ directory instead of > www/ > > 2. Unified Merges Approach > > app > |__ www/ > |__ index.html > |__ myfile.js > |__ myfile.android.js > |__ myfolder/ > |__ myfolder.android/ > > I've had much greater success with this approach. > > When a file ends with a dot platform (optional extension) name (e.g. > myfile.android.js), it will be renamed to remove the platform name (e.g. > myfile.js). This will work on both files and directories. > > This makes it extremely easy to keep track of what files and directories > are generic or platform specific. I haven't actually noticed any downside > to this approach and I used it for 2 years. > > Thoughts? > Michael >
