cordova-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lorin Beer (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CB-6453) [CLI] Experimental Refactor
Date Wed, 16 Apr 2014 17:34:14 GMT

     [ https://issues.apache.org/jira/browse/CB-6453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Lorin Beer updated CB-6453:
---------------------------

    Description: 
[editing in progress]

I've started an experimental refactor of the Cordova CLI. This is to improve the overall code
quality, and solve issues which face projects which consume Cordova CLI as a dependency.

The refactor will drastically change how the CLI operates internally, but will be backwards
compatible and nonbreaking.

# goals

- improve project stability when used as a cli
- improve project stability when consumed as an api
- improve modularization of code
- non breaking

# architecture
currently: 
CDV. 
    BUILD
    CREATE
    ....

the goal
CLI
    cli/build
        cordova/build
    cli/create
        cordova/create
    ....
CDV.
    cordova/build
    cordova/create
    ....

while initially looking more complex, this architecture forces us to eat our own dog food:
we create an api, then expose it as a cli. 

# Current State
- cli/api functionality is jumbled together
- cannot include api functionality without pulling in cli as well (or individually require'ing
files)
- difficult to diagnose simple bugs due to poor modularization

# Future State
- improved stability
- improved contributor sanity (easier to workwith)
- consume our own product (the api) insuring that releases are more stable
- bugs related to i/o can be isolated from core functionality without having to maintain complex
tests 

  was:
[editing in progress]

I've started an experimental refactor of the Cordova CLI. This is to improve the overall code
quality, and solve issues which face projects which consume Cordova CLI as a dependency.

The refactor will drastically change how the CLI operates internally, but will be backwards
compatible and nonbreaking.

# goals

- improve project stability when used as a cli
- improve project stability when consumed as an api
- improve modularization of code
- non breaking

# architecture
currently:
# 
CDV. 
    BUILD
    CREATE
    ....
the goal
CLI
    cli/build
        cordova/build
    cli/create
        cordova/create
    ....
CDV.
    cordova/build
    cordova/create
    ....

# Current State
- cli/api functionality is jumbled together
- cannot include api functionality without pulling in cli
    


> [CLI] Experimental Refactor
> ---------------------------
>
>                 Key: CB-6453
>                 URL: https://issues.apache.org/jira/browse/CB-6453
>             Project: Apache Cordova
>          Issue Type: Improvement
>          Components: CLI
>            Reporter: Lorin Beer
>            Assignee: Lorin Beer
>              Labels: experimental, proof-of-concept
>
> [editing in progress]
> I've started an experimental refactor of the Cordova CLI. This is to improve the overall
code quality, and solve issues which face projects which consume Cordova CLI as a dependency.
> The refactor will drastically change how the CLI operates internally, but will be backwards
compatible and nonbreaking.
> # goals
> - improve project stability when used as a cli
> - improve project stability when consumed as an api
> - improve modularization of code
> - non breaking
> # architecture
> currently: 
> CDV. 
>     BUILD
>     CREATE
>     ....
> the goal
> CLI
>     cli/build
>         cordova/build
>     cli/create
>         cordova/create
>     ....
> CDV.
>     cordova/build
>     cordova/create
>     ....
> while initially looking more complex, this architecture forces us to eat our own dog
food: we create an api, then expose it as a cli. 
> # Current State
> - cli/api functionality is jumbled together
> - cannot include api functionality without pulling in cli as well (or individually require'ing
files)
> - difficult to diagnose simple bugs due to poor modularization
> # Future State
> - improved stability
> - improved contributor sanity (easier to workwith)
> - consume our own product (the api) insuring that releases are more stable
> - bugs related to i/o can be isolated from core functionality without having to maintain
complex tests 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message