cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Murat Sutunc <>
Subject RE: Cordova --list option implementation
Date Thu, 08 Jan 2015 22:48:07 GMT
I think we have a couple of options here:

Option 1 - Adding --list as an optional parameter to cordova run
List is related to run and there’s not that much need to introduce another top level command
for this . Considering all the previous discussions we had I can see two potential implementations
for this:
                A) look at the parameters of run call in platform level and take action
                B) look at the parameters of run call in lib level and take action
Option 1.A results in errors or unexpected behavior on platforms that do not support --list
(including older versions).
Option 1.B involves parsing arguments in cordova-lib\cordova-lib\src\cordova\run.js (along
with the cli). From this point instead of calling project_root/platforms/<platform>/cordova/run
we can call project_root/platforms/<platform>/cordova/lib/list-* and so on. 

Option 2 - Adding ‘list’ as an optional parameter to a new command.
List can be put under a new top level command such as target. This design involves adding
a new top level command and corresponding handler in cordova-lib. Similar to run, the code
with logic will reside somewhere like cordova-lib\cordova-lib\src\cordova\target.js.

I would like to get some feedback about these options.

-----Original Message-----
From: Murat Sutunc [] 
Sent: Tuesday, January 6, 2015 5:42 PM
Subject: RE: Cordova --list option implementation

The feedback is definitely very valuable. I was trying to understand the issues with the existing
design and once the impact is realized all the commits are immediately reversed.
I'm currently looking into your suggestions and will try to come up with a better design.

-----Original Message-----
From: Josh Soref []
Sent: Tuesday, January 6, 2015 10:40 AM
Subject: Re: Cordova --list option implementation

Parashuram wrote:
>Josh, is your concern that ‹list throws an error in case of blackberry?

No. my concern is that the way this was done was wrong <PERIOD>.
It doesn't work for *ANY* project that exists today with *ANY* platform.

Cordova's design is to be backwards compatible. The code that was written absolutely failed

I tried to hint at that in my review comments.

But that was totally ignored.

Note that list threw an error in android (@released) too (as Andrew belatedly noted).

>We could fix that by either
>1a- Ignoring unknown flags like other platforms - and document the 
>ignoring part as the default behavior

This is too late. You can't really change the behavior because cordova-cli/cordova-lib needs
to support old projects with old platforms.

>1b - or change other platforms to throw error on unsupported flags. In 
>this case, ‹list would do the check to see if ‹list is implemented first.

You can't do this for the same reason that we can't do 1a.

>2. Implement ‹list for blackberry, thereby not having error on any 
>platform. We could then have a separate discussion about what happens 
>when a flag is not supported by a platform.

It's not specific to blackberry10, it applies to all existing platforms which happen to have
the underlying support but which shipped without an imaginary change to run.js

>It would be great if we can let users use the ‹list functionality with 
>minimal disruption to any platform.

Correct. And this is trivially done -- put the code into cordova-lib and have it run the scripts
from the platforms, instead of requiring changes to platforms — they already did the work
they need to do (they are free to replace their existing impls w/ node.js impls if they haven't
already, but that's transparent to cordova-lib).
 ] ][  X  ܚX P ܙݘK \X K ܙ B  ܈Y][ۘ[  [X[  K[XZ[
 ] Z[ ܙݘK \X K ܙ B

To unsubscribe, e-mail:
For additional commands, e-mail:
View raw message