Is it good practice to store Nuget or NPM (or other) packages in the source control with the source, or to keep them in some other place?

My gut says they belong with the source, however a package will probably version less often then the source, i.e. when a release version is created.

I'm wondering what others people do.


3 Answers 3


I suggest you don't for the following reasons:

  • They can take up a lot of space in your version control system
  • They are unnecessary because these should be fetched as part of your build process
  • Usually you don't care about the history of these files
  • Typically version control systems handle binary data badly

The advantages storing them in source control are:

  • You may not have access to an internet connection, but you have access to source control
  • May save some time on the initial build if your internet connection is slow
  • All good points. Cheers.
    – BanksySan
    Commented Nov 1, 2016 at 20:28
  • Give me upvotes!
    – Matthew
    Commented Nov 1, 2016 at 21:25

No. Don't store them beside your source code. Most VCS are built to handle text files, not binaries.

However, you probably should set up your own local package server and have your build fetch your dependencies from there. It gives you the safety net to avoid problems like this. TL;DR: A guy unpublished 17 lines of code and broke the Internet. That wouldn't have happened if everyone took my advice and kept their own package server.


As a general rule, you don't store artifacts in your version control system, because you should be able to rebuild them from source as needed.

One alternative is to upload your artifacts to a known location, which can be backed up (or something like Amazon S3, which has redundant storage). Another, usually better, alternative is to use a repository manager, such as Nexus.

In practice, if you have a centralized version control system it doesn't matter very much whether you store artifacts in the repository or not, as long as you structure your VCS so that users don't have to download them. With Subversion, for example, you can have a separate tree for artifacts (along with trunk/branches/tags).

However, if you're using a distributed VCS, like Git, you definitely don't want to store artifacts in the repository. The reason is that you download the entire repository with Git, including all obsolete versions of all files. That can take an unpleasantly long time even if it just holds source code (try checking out the AWS Java SDK for example).

  • I'm pretty sure you don't download every branch on the remote repository, just the master and then whichever ones you pull down.
    – BanksySan
    Commented Nov 1, 2016 at 21:06
  • 1
    @BanksySan - It walks the object trees starting at the remote refs (all branches and tags) -- it has to, otherwise you couldn't check out an arbitrary branch without connecting to the server, which would defeat the point of a DVCS. If it's in any reachable commit chain, which would include any released artifact, it will be in your local clone.
    – kdgregory
    Commented Nov 1, 2016 at 21:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.