Should we clone all production dependancies?

Question

Very recently Ant Design&rsquo;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?

Someone · Accepted Answer

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.

tracer4201 · Answer

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&rsquo;s in our company&rsquo;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?

pestatije · Answer

> we are running several dependencies in production> automatically pull future commitsYou are very trustful. Those two are a big no-no. Dependencies should be curated.