cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitry Blotsky <>
Subject RE: Reason for node_modules in Platform Repos
Date Fri, 19 Dec 2014 23:46:52 GMT
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:

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:



-----Original Message-----
From: [] On Behalf Of Brian LeRoux
Sent: Friday, December 19, 2014 1:04 PM
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 <> 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:// instead of …
> 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.
View raw message