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:07:10 GMT
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