cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vladimir Kotikov (Akvelon)" <v-vlk...@microsoft.com>
Subject RE: [Discuss] Cordova-common release
Date Tue, 29 Sep 2015 08:27:23 GMT
Agree with you, guys.

Unfortunately, the underlying modules in `cordova-common` are not really atomic, since they
depending on each other. For example ConfigParser requires `xmlHelpers`, `events` and `CordovaError`
as a dependencies. Reworking them to be truly separated might be sort of problematic, especially
in context of message logging (as they use shared event emitter to log output to console).

So I still propose is to release `common` module as-is and then gradually move inner modules
out to separate packages.

-
Best regards, Vladimir.

-----Original Message-----
From: Carlos Santana [mailto:csantana23@gmail.com] 
Sent: Friday, September 25, 2015 7:33 PM
To: dev@cordova.apache.org
Subject: Re: [Discuss] Cordova-common release

Sorry a typo
to use "bundleDependencies" you will have a node_modules/ directory directly under "common/node_modules/cordova-error/"

and the the small modules (i.e. cordoba-util, cordova-plugin-info, etc..) will be located
there.

then have explicit ignores for the dependencies you don't want to be source control like npm
[2]

[2]: https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2fnpm%2fnpm%2fblob%2fmaster%2f.gitignore%23L24&data=01%7c01%7cv-vlkoti%40064d.mgd.microsoft.com%7c73b4ff38f0fe41e1f18608d2c5c70e0f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=tU%2bFHDUJZXzXnbG%2fUP7AY4qECnvsbnsJ%2bvEriJvqYcU%3d


On Fri, Sep 25, 2015 at 12:24 PM Carlos Santana <csantana23@gmail.com>
wrote:

> Yes after reviewing the changes, I understood the purpose of the code 
> that you seperated to avoid duplicate code between the other top level 
> modules (i.e. platforms, lib, cli)
>
> I still think small modules is the way to go.
>
> Don't let process, bureaucracy, and ceremony hamper the engineering 
> process and the consumer UX using this modules.  (yeah that came out 
> from the mouth of an IBMer ;-p)
>
> Yes, I'm not blind, I understand the voting, the releasing, the 
> packaging the publish steps
>
> The way I look at it no matter what you do you are not going to make 
> it easier by having one "common" package.
>
> Let's say you just need to update a file to fix a bug from Error, well 
> you need to test, vote, release, "common"
> Next you want to fix a bug in configparser, guess what you need to 
> tests, vote, release "common" again But if only config parser changed 
> all the rest of the code in "common"
> needs to be tested and release, and consumer will need to pick a new 
> common for only a small bug fix in a portion of "common"
>
> Basically that's what we have today, the way I see it you are just 
> creating two libs "lib" and "lib2"
>
> With large number of small modules, lets say we create 8 now, maybe 
> only 2 change most of the time, and the other 5 are so basic and small 
> that they never change and stay at version 1.0.0 for  long time.
>
> I think for this small modules, I don't think we have to do the blog 
> post, twitter things, those I will continue to have for the large 
> components (cli, platforms, plugins)
>
> Also the side effect I would like to see, is clean APIs edges, each 
> small module provides an API, it contain tests to that API, and lib 
> contain integration tests as a whole.
>
> Maybe the compromise for now, to move forward let's break the 
> functions into "npm packages" inside this "common" where each sub 
> directory inside common is a npm package with a single entry point 
> (index.js) and common package.json have them as "bundleDependencies", 
> similar way as npm does [1]
>
> the transition will be for consumers for their dependencies and the 
> way they consume the API
> dependencies: {
>    cordova-common: "1.0.0"
> }
> cordova-common only expose one index.js with the APIs to the other 
> modules
>
> var cdvUtil              = require("cordova-common").cordova-util
> cdvPluginInfo          = require("cordova-common").cordova-plugin-info,
> cdvError                  = require("cordova-common").cordova-error,
> cdvConfigParser     = require("cordova-common").cordova-config-parser,
> cdvConfigChanges = require("cordova-common").rcordova-config-changes);
>
> then it can be easier transition if we want to change later, nothing 
> much on our part since we already have the npm packages implemented 
> it's a matter if we want to make them available on npm or not.
>
> [1]: 
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithu
> b.com%2fnpm%2fnpm%2fblob%2fmaster%2fpackage.json%23L137&data=01%7c01%7
> cv-vlkoti%40064d.mgd.microsoft.com%7c73b4ff38f0fe41e1f18608d2c5c70e0f%
> 7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=tUdBPvbE8oC3DPubmVx50QKD2
> CLfoxrVgj%2ftTxTrMJ8%3d
>
>
>
>
>
> On Fri, Sep 25, 2015 at 11:40 AM Sergey Grebnov (Akvelon) < 
> v-segreb@microsoft.com> wrote:
>
>> I tend to agree w/ Carlos here, but from practical side it might be 
>> very hard to maintain and release such a granular modules, for 
>> example,
>>  -  cordova-error has been updated ->Vote -> update 
>> cordova-config-parser
>> + Vote-> update + Vote other depended modules
>> - now we want to add some new feature: modules are very granular so 
>> we should introduce a new module
>>
>> But I totally love and support Carlos idea regarding grouping 
>> meaningful/independent logic in modules, this is how software must be 
>> designed.
>>
>> I personally think about this new module as some sort of core Cordova 
>> functionality and high level classes which could be used by 
>> cordova-lib/cli and platforms -unified CordovaError, events (output 
>> tracing, etc), working with config file, superspawn, etc
>>
>> Thx!
>> Sergey
>> -----Original Message-----
>> From: Carlos Santana [mailto:csantana23@gmail.com]
>> Sent: Thursday, September 24, 2015 6:31 PM
>> To: dev@cordova.apache.org
>> Subject: Re: [Discuss] Cordova-common release
>>
>> Sorry if I take my inner purist theoretical developer out for a 
>> minute :-)
>>
>> The point of having a "node module" it should be explicit and small, 
>> meaning that should be easy to name in a way that describes what it 
>> is or do.
>>
>> Take into account that "node module" is not the same as a "npm package"
>>
>> Having 2 npm packages on the npm registry "cordova-common" and 
>> "cordova-lib" to the simple eye would look like duplicate packages, 
>> and then will need to answer multiple times "What is the difference 
>> between lib and common?"
>>
>> Why not have more smaller explicit npm packages instead?
>>
>> cordova-util
>> cordova-plugin-info
>> cordova-error
>> cordova-config-parser
>> cordova-config-changes
>>
>> each one with a index.js exposing APIs
>>
>> Then the programing model becomes something like this:
>> var cdvUtil              = require('cordova-util'),
>> cdvPluginInfo          = require('cordova-plugin-info'),
>> cdvError                  = require('cordova-error'),
>> cdvConfigParser     = require('cordova-config-parser'),
>> cdvConfigChanges = require('cordova-config-changes');
>>
>>
>> On Thu, Sep 24, 2015 at 12:29 PM Sergey Grebnov (Akvelon) < 
>> v-segreb@microsoft.com> wrote:
>>
>> > Hi guys - we've decided to combine shared logic as cordova-common 
>> > module and publish it separately (read [1] for more details).
>> > Corresponding change has landed to master[2] on last week so I'm 
>> > wondering if we should release this module and then update LIB to 
>> > rely
>> on it (similar to cordova-serve).
>> > So guys it will be great if we can review it one more time 
>> > (including the name - do we all  agree to use cordova-common??)  
>> > and then do release - I'll be able to help w/ merging the recent 
>> > changes added to LIB before doing release.
>> >
>> > [1]
>> > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fis
>> > sue 
>> > s.apache.org%2fjira%2fbrowse%2fCB-9598&data=01%7c01%7cv-segreb%40mi
>> > cro 
>> > soft.com%7cf31529ebb0de4bf28ebd08d2c54915f3%7c72f988bf86f141af91ab2
>> > d7c 
>> > d011db47%7c1&sdata=oeX8CbX%2bQGJsvf9%2fW2KFWAkUw6NAlb0LMOorTjwXTXk%
>> > 3d
>> > [2]
>> > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgi
>> > thu 
>> > b.com%2fapache%2fcordova-lib%2ftree%2fmaster%2fcordova-common&data=
>> > 01%
>> > 7c01%7cv-segreb%40microsoft.com%7cf31529ebb0de4bf28ebd08d2c54915f3%
>> > 7c7
>> > 2f988bf86f141af91ab2d7cd011db47%7c1&sdata=o0EwRydALocXUrr4I9ASfQMku
>> > RV0
>> > ksMKA%2fp2zpg6BNU%3d
>> >
>> > Thx!
>> > Sergey
>> >
>> > -------------------------------------------------------------------
>> > -- To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>> > For additional commands, e-mail: dev-help@cordova.apache.org
>> >
>> >
>>
>
Mime
View raw message