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