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