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 Wed, 30 Sep 2015 09:27:43 GMT
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
Mime
View raw message