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://github.com/npm/npm/blob/master/.gitignore#L24 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://github.com/npm/npm/blob/master/package.json#L137 > > > > > > 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%2fissue >> > s.apache.org%2fjira%2fbrowse%2fCB-9598&data=01%7c01%7cv-segreb%40micro >> > soft.com%7cf31529ebb0de4bf28ebd08d2c54915f3%7c72f988bf86f141af91ab2d7c >> > d011db47%7c1&sdata=oeX8CbX%2bQGJsvf9%2fW2KFWAkUw6NAlb0LMOorTjwXTXk%3d >> > [2] >> > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithu >> > b.com%2fapache%2fcordova-lib%2ftree%2fmaster%2fcordova-common&data=01% >> > 7c01%7cv-segreb%40microsoft.com%7cf31529ebb0de4bf28ebd08d2c54915f3%7c7 >> > 2f988bf86f141af91ab2d7cd011db47%7c1&sdata=o0EwRydALocXUrr4I9ASfQMkuRV0 >> > ksMKA%2fp2zpg6BNU%3d >> > >> > Thx! >> > Sergey >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org >> > For additional commands, e-mail: dev-h...@cordova.apache.org >> > >> > >> >
