cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Max Woghiren <m...@chromium.org>
Subject Re: [cordova-cli] Merges Directory
Date Tue, 26 Mar 2013 15:36:36 GMT
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 <michael@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
>

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