cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlos Santana <csantan...@gmail.com>
Subject Re: [Discuss] Cordova-common release
Date Fri, 25 Sep 2015 16:33:08 GMT
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 <csantana23@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-segreb@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:csantana23@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-segreb@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-unsubscribe@cordova.apache.org
>> > For additional commands, e-mail: dev-help@cordova.apache.org
>> >
>> >
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message