Hey folks, Thanks for the feedback! I agree with Josh, that requiring active dependency resolution introduces an extra point of failure. Even if a corporate network is fast and reliable, it has been explained to me that it is possible for a third-party dependency provider to pull their package from NPM, thus breaking a platform install. Keeping the dependency code inside the platform repo makes the code more robust. That does seem like a valid reason to do things the way we are doing them. Perhaps though, it should be mentioned in the documentation that that is how package repositories handle dependencies. I created a JIRA issue for this: https://issues.apache.org/jira/browse/CB-8195.
As for getting feet wet, I am currently getting up to speed with the effort to get Cordova Medic on Apache Infrastructure, as per this JIRA ticket: https://issues.apache.org/jira/browse/INFRA-8588. Kindly, Dmitry -----Original Message----- From: brian.ler...@gmail.com [mailto:brian.ler...@gmail.com] On Behalf Of Brian LeRoux Sent: Friday, December 19, 2014 1:04 PM To: dev@cordova.apache.org Subject: Re: Reason for node_modules in Platform Repos Josh, you are really abrasive and need to work on that. The corp network thing isn't a reason for anyone except RIM and Adobe IT departments and even then its not a real reason. If we architect for bad IT departments we may as well go full Apache Way and have singular SVN repo with <50% uptime and a 10 year release cycle. These are not hand waving statements. Using a package.json for deps is a well documented and understood practice. Someone *should* write some code and this would be a great first patch for a new developer looking to get their feet wet with the project. On Fri, Dec 19, 2014 at 12:48 PM, Josh Soref <jso...@blackberry.com> wrote: > Brian LeRoux wrote: > >yeaaaah, we've been through this in other threads. pin the dep in > >package.json to a version or sha and your problem is solved. the only > >time a node_modules should be checked in, maybe, is in a deployment > >scenario for hosted service type things. > > > >(bad corp networks aside!) > > Bad corporate networks exist. And they block ssh: (I.e. git:). > > It's really painful to have things fail just because someone decided > to use git://github.com instead of https://github.com … > > > > I'm also pretty sure that we don't currently have the right code to > actually get dependencies and install them when we do a platform add. > So while you may want to make a hand waving statement about "we should > stop doing this", someone would almost certainly have to write code to > make it do the right thing. > > Further, that doesn't fix the case I've described above. > > I don't see a reason to change the status quo, and I have identified a > reason not to change it. >
