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