>From a technical standpoint, checking them in was easier. You can install a platform from a git URL, or from a directory, or from npm. None of these ways currently knows how to fetch the package's node dependencies (fetching from npm we use "cache add", which doesn't grab deps). Quite possibly though, it'd be better for at least the npm fetch case to grab the deps from npm.
>From a design standpoint, at one point we were trying to maintain a way to have offline installs of Cordova. This was mostly an ask from Marcel - that Cordova be usable when distributed via .zip files. Not sure if this is still much of an issue? On Sat, Dec 20, 2014 at 1:12 PM, Brian LeRoux <b...@brian.io> wrote: > > First link from a Google search about checking in node modules. > > > http://stackoverflow.com/questions/11459475/should-i-check-in-node-modules-to-git-when-creating-a-node-js-app-on-heroku > > While useful to question assumptions (always) we should also strive to > respect the best practices and standards for the platforms we target. Maybe > that's obvious but bears repeating. > > On Friday, December 19, 2014, Dmitry Blotsky <dblot...@microsoft.com> > wrote: > > > 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 <javascript:;> [mailto: > brian.ler...@gmail.com > > <javascript:;>] On Behalf Of Brian LeRoux > > Sent: Friday, December 19, 2014 1:04 PM > > To: dev@cordova.apache.org <javascript:;> > > 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 > > <javascript:;>> 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. > > > > > >
