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: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%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 > > <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
