Ask HN: Should we clone all production dependancies? | Hacker News Reader

Ask HN: Should we clone all production dependancies?

3 pointsgervwyk8 comments

Very recently Ant Design’s Github repo got hacked and the code was removed. Of course the team reacted quickly and the code was back up [0]

But this got me thinking, we are running several dependencies in production, what if one of them where to be removed, how will we maintain the project in the future? Yes, the build will be on npm, but what if needed to fix bugs or make changes. It could set us back months to replace a dependency such as antd.

Is this something we need to worry about? If so, will it be best to clone the source? What's best practice for this, should we fork or clone? And can we automatically pull future commits?

View on HN

Best practice is to have a local repo that caches every package your code depends on. See https://en.wikipedia.org/wiki/Software_repository#On-Premise... for tools.

Your code then should resolve all its dependencies through that cache. If the cache doesn’t have it yet it goes to the real repo to resolve it. Then, it gives you its copy.

You typically can also use these products to store/archive any binaries you produce.

I don’t know how well these work if, as you say, you want to automatically pull future commits. That feels like a dangerous practice to me.

Thanks. Yes, just meant keeping a local copy of the repo from a maintenance / future proof perspective, but obviously still curate next versions before including into build.

At my last company we had our own copy of every dependency we used, sometimes multiple versions. For a while every dependency had to get approved (someone would literally look at the license and verify it’s in our company’s approved list of licenses). This was after a contractor used some dependency that he had written himself, left the company, and then tried to sue us.

But we never took a dependency on any external code repository. Imagine that external service goes down. Would you be able to afford having blocked builds?

That's a funny story. Yes, we also check licenses, security, popularity and maintainers before introducing a dependency. Then of course again track changes for every future release so there is a significant overhead to for every dependency.

When you say never took on any external code repository does it mean you guys would make a copy of every package you add, build it yourself and not use something like npm dependencies in production?

Yes, exactly the latter. Our build system actually blocked any kind of network call to external services. Every dependency and transitive dependency was hosted in house.

> we are running several dependencies in production

> automatically pull future commits

You are very trustful. Those two are a big no-no. Dependencies should be curated.

Yes. Of course curating dependencies is super important. What I meant by automatically pull future commits is to keep the clone updated. I’m concerned about future maintainability should the main repo be removed from GitHub for whatever reason.

From a security perspective we go into all details before introducing a dependency and track changes on future version - this is also currently a very manual process, not sure how this could be done better aswell.

yes, security and malicious updates on hacked repos is another concern

Reply on news.ycombinator.com