cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <mmo...@chromium.org>
Subject Re: Move platform parsers from CLI to platforms
Date Mon, 09 Feb 2015 22:12:04 GMT
You know, writing out my thoughts has crystallized that I think we should
just be shipping the scripts as independent packages instead of bundling
directly inside platforms.

With that conclusion, I have to re-think what that implies ;)

On Mon, Feb 9, 2015 at 5:07 PM, Michal Mocny <mmocny@chromium.org> wrote:

> Thoughts:
>
> 1. I'm happy to require cordova-android@FOO is required to be installed
> if you want to prepare a project that was created with it.  I think we
> should leave a "created-with" file inside the platform artifacts to confirm
> this.  Possibly it makes in-place upgrades harder, but I think the future
> of upgrade is uninstall-update-install or rm -rf && add
>
> 2. To support older platforms, I suggest we create a new package
> (cordova-platform-scripts-legacy?), which simulate as-if old platforms had
> scripts embedded.  This way, we can write the CLI/LIB tooling parts without
> many special cases, and gives us easier ability to polyfill the legacy
> scripts to future CLI/LIB api changes.
>
> 3. Regarding making refactoring harder.. maybe.  Or maybe we have
> cordova-android depend on cordova-android-scripts and use semver.  If the
> cordova-android-scripts change, but are backwards compatible, we can push
> an update that will automatically be picked up by all older platforms.  If
> it isn't compatible, then you have a tooling-platform mismatch and have to
> upgrade no matter what.
>
> 4. Agree with assuming everything async -- and personally prefer promises
> (they are in io.js by default, node just updated to 0.12, may be there soon
> too) -- but I know there were some reservations on this lists about using
> them.  (We can wrap one way with the other, so lets not bikeshed for now)
>
> On Mon, Feb 9, 2015 at 9:45 AM, Andrew Grieve <agrieve@chromium.org>
> wrote:
>
>> Been thinking about this as well, and one part I'm not 100% sure about is
>> having this logic at create-time vs prepare-time vs plugin-add time.
>>
>> create-time - easy to see we just put it in cordova-FOO and allow deps
>> within package.json
>>
>> prepare/plugin-add time though, should we relay on having the correct
>> version of cordova-FOO around to use, or should we copy this logic into
>> platforms/FOO/cordova?
>>
>> Moving these files into each repo will certainly make refactoring harder.
>> E.g., making a change to the API now requires a version check + still
>> supporting the old API + also supporting the new API. Still think this is
>> worth doing, but I think we should also consider sanity-checking our API
>> surface to ensure that it makes the most sense (e.g. all APIs that may
>> have
>> to do IO should return promises, even if they are sync right now).
>>
>>
>> On Mon, Feb 9, 2015 at 12:42 AM, Mark Koudritsky <kamrik@google.com>
>> wrote:
>>
>> > There are 2 main places in the lib with platform specific logic
>> > src/cordova/metadata/<platform>_parser.js
>> > src/plugman/platforms/<platform>.js
>> > Probably all of this logic should be moved to platforms.
>> >
>> > On Sun, Feb 8, 2015 at 4:36 AM, Josh Soref <jsoref@blackberry.com>
>> wrote:
>> >
>> > > +1
>> > > ‎
>> > > Sent from my BlackBerry 10 smartphone.
>> > >
>> > >
>> >
>>
>
>

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