cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlos Santana <csantan...@gmail.com>
Subject Re: [Discuss] Cordova-common release
Date Wed, 30 Sep 2015 11:07:01 GMT
Yes temporary, maybe we can discuss some more in F2F

I still do not understand what are you trying to solve by having all that content published
as big blob. 

If the packages are only for Cordova components to depend on then we control the release and
we can include them easily. 

If the code is to be share by third party or anyone out there then it make sense to put in
npm. 

One concrete example is cordova-configparser, Our IBM tool is using it in our own models code
so today we taking a copy, if it's available thru npm then we can stated as a dependency and
manage it as a npm package vs a loosely node module js file

Maybe not all classes need to be converted to npm packages maybe it can be some
cordova-configparser 
cordova-utils 
cordova-helper

Also do some refactoring and dependency cleaning, I saw a node module dependeding on underscore
and the file only had one simple call to _.find()

We were going to use that module, but then decided not to since it depended on underscore
for a simple thing, this creates legal clearance work and more dependencies we need to include
in our product making our download larger. 

And yes, yes we bundle all our dependencies when we go into production. 

- Carlos
Sent from my iPhone

> On Sep 30, 2015, at 5:27 AM, Vladimir Kotikov (Akvelon) <v-vlkoti@microsoft.com>
wrote:
> 
> Including cordova-common as bundled dependency should be enough in our case. Changes
to coho are submitted already [1], so we only need to update package.json for cordova-lib.

> 
> Personally  for me bundling looks like a temporary workaround before we get all those
partials of 'common' published to npm, am I right?
> 
> [1] https://github.com/apache/cordova-coho/pull/94
> 
> -
> Best regards, Vladimir.
> 
> -----Original Message-----
> From: Carlos Santana [mailto:csantana23@gmail.com] 
> Sent: Tuesday, September 29, 2015 9:15 PM
> To: dev@cordova.apache.org
> Subject: Re: [Discuss] Cordova-common release
> 
> Do we need to absolutely publish this to npm?
> 
> Can we just include the dependency in the platform as a bundle dependency?
> 
> We just need to update coho to npm install/link the cordoba-common package when doing
a release of what ever component need it? (i.e. cordova-android)
> 
> Will this get you what you want? Why does it absolutely need to be in npm registry?
> 
> I really don't think will be a good idea to publish two npm packages "cordova-lib" and
"cordova-common"
> 
> Sorry if I'm being a pain in the ass, maybe I'm something obvious here
> 
> 
>> On Tue, Sep 29, 2015 at 1:34 PM Steven Gill <stevengill97@gmail.com> wrote:
>> 
>> Sounds good. Let's move forward
>> On Sep 29, 2015 10:21 AM, "Nikhil Khandelwal" <nikhilkh@microsoft.com>
>> wrote:
>> 
>>> +1. I understand the value of Carlos' proposal, but in the spirit of
>>> moving forward with this which is fairly complicated refactor 
>>> involving multiple releases and repos, I would like us to make 
>>> progress on this
>> soon
>>> and not add significant scope to this effort.
>>> 
>>> 
>>> -Nikhil
>>> 
>>> -----Original Message-----
>>> From: Sergey Grebnov (Akvelon) [mailto:v-segreb@microsoft.com]
>>> Sent: Tuesday, September 29, 2015 1:34 AM
>>> To: dev@cordova.apache.org
>>> Subject: RE: [Discuss] Cordova-common release
>>> 
>>> +1
>>> 
>>> -----Original Message-----
>>> From: Vladimir Kotikov (Akvelon) [mailto:v-vlkoti@microsoft.com]
>>> Sent: Tuesday, September 29, 2015 11:27 AM
>>> To: dev@cordova.apache.org
>>> Subject: RE: [Discuss] Cordova-common release
>>> 
>>> 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%2fgithu
>> b.com%2fnpm%2fnpm%2fblob%2fmaster%2f.gitignore%23L24&data=01%7c01%7cv-
>> vlkoti%40064d.mgd.microsoft.com%7c73b4ff38f0fe41e1f18608d2c5c70e0f%7c7
>> 2f988bf86f141af91ab2d7cd011db47%7c1&sdata=tU%2bFHDUJZXzXnbG%2fUP7AY4qE
>> CnvsbnsJ%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%2fg
>>>> ithu
>>>> b.com%2fnpm%2fnpm%2fblob%2fmaster%2fpackage.json%23L137&data=01%7c
>>>> 01%7 
>>>> cv-vlkoti%40064d.mgd.microsoft.com%7c73b4ff38f0fe41e1f18608d2c5c70
>>>> e0f%
>>>> 7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=tUdBPvbE8oC3DPubmVx50
>>>> QKD2
>>>> 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%7c72f988bf86f141af9
>>>>>> 1ab2
>>>>>> d7c
>>>>>> d011db47%7c1&sdata=oeX8CbX%2bQGJsvf9%2fW2KFWAkUw6NAlb0LMOorTjwX
>>>>>> TXk%
>>>>>> 3d
>>>>>> [2]
>>>>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%
>>>>>> 2fgi
>>>>>> thu
>>>>>> b.com%2fapache%2fcordova-lib%2ftree%2fmaster%2fcordova-common&d
>>>>>> ata=
>>>>>> 01%
>>>>>> 7c01%7cv-segreb%40microsoft.com%7cf31529ebb0de4bf28ebd08d2c5491
>>>>>> 5f3%
>>>>>> 7c7
>>>>>> 2f988bf86f141af91ab2d7cd011db47%7c1&sdata=o0EwRydALocXUrr4I9ASf
>>>>>> QMku
>>>>>> 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
>>> 
>>> --------------------------------------------------------------------
>>> - To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
>>> For additional commands, e-mail: dev-help@cordova.apache.org
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org


Mime
View raw message