If we manage to get down to 1 module === 1 function then its doubtful we'd have much advantage to the atomic commits thing. I'm cool w/ starting w/ one repo and seeing where it leads. Sort of a graduation step thing.
On Mon, Apr 14, 2014 at 12:02 PM, Michal Mocny <[email protected]> wrote: > Alright then, lets do 3+ npm packages: cordova (cli only), plugman (cli > only), and cordova-lib (or something similarly named, TBD, suggestions?). > As cordova-lib refactors to have some useful self-contained utils, we will > move those to dedicated npm modules published separately. > > However, we are currently debating the use of a single vs multiple git > repos to hold the modules. > > The advantages of single repo: > - Easier to create atomic commits to multiple npm modules (there are often > multi-part changes), which is especially true for external Pull Requests. > - More likely that we will be willing to move utils out to dedicated npm > modules if there is no additional repo/release management overhead. > > The advantages of multiple repos: > - Easier to isolate github issues (though we don't really use these), and > Pull Requests. Note: does not affect git logs, which are easy to filter > based on subdirectory. > - We already have cordova-cli and plugman repos anyway. > - "Feels" cleaner? > > -Michal > > > > > On Mon, Apr 14, 2014 at 2:13 PM, Anis KADRI <[email protected]> wrote: > > > To brian and steve's points I think it's a bad idea to move common code > to > > cordova-cli. I don't think we want another cordova-coho. > > > > > > On Fri, Apr 11, 2014 at 5:36 PM, Brian LeRoux <[email protected]> wrote: > > > > > It would be very good for folks to understand the benefit of using npm > is > > > that we will likely only have to release these small modules very > rarely. > > > Once the module is out the dependency part is done. This is vastly > > simpler > > > workflow, smaller codebases to reason about, quicker to test, and > easier > > to > > > ship small releases. If the small module is only applicable to Corodva > > that > > > is fine and good. > > > > > > This is less complicated. It is easier to share code that is in > modules. > > > Adding them to the same repo is no different than adding it to the > > > package.json and require'ing it in from a programming perspective (but > it > > > does add overhead of a large codebase in a single repo). > > > > > > Having large monolith codebases is considered a poor practice in Node > > based > > > projects and most of Cordova today is a Node based project. I recommend > > > learning more about the philosophy and reasoning for these practices. > We > > > don't need to 'conform' to all Node-isms (like favoring callbacks to > > > promises or streams to sync i/o operations) but the committers here > would > > > do well to understand those primitives and the motivations for them. > > > > > > > > > > > > On Sat, Apr 12, 2014 at 5:42 AM, Mark Koudritsky <[email protected]> > > > wrote: > > > > > > > On Fri, Apr 11, 2014 at 2:53 PM, Steven Gill <[email protected] > > > > > > wrote: > > > > ... > > > > > > > > > > > > > I'd love to get more details about your proposed first patch. What > do > > > you > > > > > mean by "Move internal implementation details of plugman into > > > > > cordova". I interpret it as move common functionality into cli, > make > > > > > plugman dependent on cli. > > > > > > > > Yes, that's the intention. > > > > > > > > > > > > > If that is the case, wouldn't it make more sense > > > > > to move the functionality into plugman since the cli already > requires > > > it? > > > > > > > > > There is no big difference which way to move the code as long as it's > > > easy > > > > to share, the change is very simple either way. The cli npm package > > name > > > is > > > > "cordova" which is an argument towards keeping most of the logic > there > > > > because that's the name people know. For users the change will be > > > > transparent, plugman users will continue to "npm install plugman" and > > cli > > > > users will continue to "npm install cordova". > > > > > > > > I like the end goals of your proposal, in that we are working towards > > > > > smaller modules. I'm not sure if moving components from one repo to > > > > another > > > > > is a better way to reach the end goal, instead of Mark's original > > > > > suggestion of a third cordova-lib repo that both plugman + cli can > > > depend > > > > > on. > > > > > > > > The end goal of my proposal is simplified development workflow > without > > > > complicating release workflow. > > > > > > > > Right now I'm working on a new piece of code (dealing with plugin > deps > > > and > > > > versions) that should be used in both plugman and cli. While it seems > > > like > > > > it should be trivial, at a closer look there is currently no clean > way > > to > > > > share such code between cli and plugman (just like xml helpers are > > > cloned). > > > > At this stage that piece of code is nowhere close to being ready for > > > > release as a separate small module, but it has a good potential to > > > > eventually become such module (though it will never be usable outside > > > > cordova). > > > > > > > > > >
