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 <mmo...@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 <agri...@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 <kam...@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 <jso...@blackberry.com> >> wrote: >> > >> > > +1 >> > > >> > > Sent from my BlackBerry 10 smartphone. >> > > >> > > >> > >> > >
