> I still do not understand what are you trying to solve by having all that > content published as big blob. Code deduplication is the main reason. All the things from 'cordova-common' will be used by platforms intensively, so we need to share this code and keep it separately from LIB to share easily. Publishing is basically doesn't required for this, and bundling 'cordova-common' into LIB is enough for this purpose.
Another reason was that third-party tool might want to use some of this functionality (like your example with ConfigParser), so we need to have this package on NPM to allow them to get it. For this case I now do agree with you that separate packages for ConfigParser, PluginInfo and other stuff looks better than putting it into one big package. - Best regards, Vladimir -----Original Message----- From: Carlos Santana [mailto:csantan...@gmail.com] Sent: Wednesday, September 30, 2015 2:07 PM To: dev@cordova.apache.org Subject: Re: [Discuss] Cordova-common release 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-vlk...@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://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithu > b.com%2fapache%2fcordova-coho%2fpull%2f94&data=01%7c01%7cv-vlkoti%4006 > 4d.mgd.microsoft.com%7cf9eefe800e4c44c0540308d2c9874d65%7c72f988bf86f1 > 41af91ab2d7cd011db47%7c1&sdata=HpV5fWkx6nUZUU%2fT4qVVo0QZiGM7%2fm%2bdo > 9WX4V4JfT0%3d > > - > Best regards, Vladimir. > > -----Original Message----- > From: Carlos Santana [mailto:csantan...@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 <stevengil...@gmail.com> wrote: >> >> Sounds good. Let's move forward >> On Sep 29, 2015 10:21 AM, "Nikhil Khandelwal" >> <nikhi...@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-seg...@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-vlk...@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:csantan...@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%2fgith >> u >> b.com%2fnpm%2fnpm%2fblob%2fmaster%2f.gitignore%23L24&data=01%7c01%7cv >> - >> vlkoti%40064d.mgd.microsoft.com%7c73b4ff38f0fe41e1f18608d2c5c70e0f%7c >> 7 >> 2f988bf86f141af91ab2d7cd011db47%7c1&sdata=tU%2bFHDUJZXzXnbG%2fUP7AY4q >> E >> CnvsbnsJ%2bvEriJvqYcU%3d >>> >>> >>> On Fri, Sep 25, 2015 at 12:24 PM Carlos Santana >>> <csantan...@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-seg...@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:csantan...@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-seg...@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-unsubscr...@cordova.apache.org >>>>>> For additional commands, e-mail: dev-h...@cordova.apache.org >>> >>> -------------------------------------------------------------------- >>> - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org >>> For additional commands, e-mail: dev-h...@cordova.apache.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
