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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> > wrote: > > > > > +1 > > > > > > Sent from my BlackBerry 10 smartphone. > > > > > > > > >
