He Commits Vendor! 😱
Boris Jamot ✊ /

Boris Jamot ✊ / @biros

About: Software Crafter 🐘 / 🐹 + 👷 = 🚀

Location:
🇫🇷 Caen, Normandy
Joined:
Aug 12, 2018

He Commits Vendor! 😱

Publish Date: Oct 17 '18
16 16

Yesterday we had an interesting discussion between some developers of different teams in my company. The subject was: « what is the point of vendoring? ».

Vendoring means committing your project's dependencies along with your code.

What happened is that some developers (including myself) discovered that some other developers commit the vendor folder in the git repository. My first reaction was pretty pejorative as I thought it was a dirty practice from another time, when we had no dependency manager. The devs explained us that it has many benefits:

  • first it allows to build your app much more faster in your CI
  • then it ensures you have the exact version of your dependencies
  • then there is no way one of them get injected by some malware dependency
  • finally you are not dependent of the network (or of the remote dependency repositories) during the build

None of these arguments satisfied me, not that they're not true, but I think each of them can be solved in a cleaner way, for example by using a cache, a custom repository with audited dependencies, and by solving directly the network issues.

And you, what do you think?

Comments 16 total

  • rhymes
    rhymesOct 17, 2018
    • first it allows to build your app much more faster in your CI

    cache as you said

    • then it ensures you have the exact version of your dependencies

    repeatable builds and exact versioning let you do that

    • then there is no way one of them get injected by some malware dependency

    what if it's already in there? It's not like you're going to audit the code of every single dependency (and their dependencies) you add but you can still use the cache for that

    • finally you are not dependent of the network (or of the remote dependency repositories) during the build

    proxy or cache as you said

    None of these arguments satisfied me, not that they're not true, but I think each of them can be solved in a cleaner way, for example by using a cache, a custom repository with audited dependencies, and by solving directly the network issues.

    Yep :-)

    It's not a bad thing to do, it's just not really needed and you end up putting your dependencies (and their dependencies) as a diff in the git log everytime you upgrade anything

  • Yoginth
    YoginthOct 17, 2018

    This will increase the size of the repo!

    • Darryl Norris
      Darryl NorrisOct 17, 2018

      This could potentially become a very big problem depends on how your app is structured. For instance, if you have a monolithic app that has, it has decoupled components (modules or whatever you want to call it), and each of them has theirs on vendor directory, this will make your app huge.

      This brings problems with IDE indexing taking forever, and even downloading the repo.

      • Yoginth
        YoginthOct 17, 2018

        Yeah exactly of course it will take too much time to index in my IDEs.

      • PNS11
        PNS11Oct 18, 2018

        It will have to be indexed and downloaded regardless of whether it's from the repo or some web storage.

        Try ripgrep or fzf, they're pretty great at fast searching.

    • Adrian B.G.
      Adrian B.G.Oct 17, 2018

      Maybe this way devs will realize how much code they really have in their app.

      Probably dead code, untested code and so on. Package managers make things so easy to throw away performance, lower level concerns and build sizes.

  • Franco Traversaro
    Franco TraversaroOct 17, 2018

    We just commit the composer.lock or the equivalent for npm project, so anyone can install exactly the right version of the dependencies. Problem solved.

  • James Wright
    James WrightOct 17, 2018

    On my personal projects I don't really bother with this.
    However, you only have to look at the NPM "leftpad" debacle to see why I ALWAYS do this in professional projects for a company.

    I've had multiple times in my career where I need to update an old project that hasn't been touched in years, that has a dependency that is no longer available (easily) online.

    • Boris Jamot ✊ /
      Boris Jamot ✊ /Oct 17, 2018

      It seems to be a good reason.
      Thx !

    • Weston Wedding
      Weston WeddingOct 19, 2018

      Yeah, at the very least, I feel like making sure you commit the dependencies for major versions of your final product is important. I don't feel like we should assume composer.json or package.json will even be enough 5 years from now. Online services come and go at a moment's notice.

  • Boris Jamot ✊ /
    Boris Jamot ✊ /Oct 17, 2018

    This has absolutely no impact on indexing in IDE. In both cases the same files are indexed. No overhead.

  • Adrian B.G.
    Adrian B.G.Oct 17, 2018

    It solves some rare problems, but real never the less. I would use it if team members have low bandwidth, or for projects that are not in active development but important.

    I imagine if the source is a problem could be saved in a git submodule or something.

  • Sanzeeb Aryal
    Sanzeeb AryalApr 28, 2021

    I think I'll need to commit the vendor directory. The vendor directory is required when deploying and I use GH actions to deploy. The vendor directory isn't in the GH, because it's gitignored. So, I obviously need to git the vendor directory? Do you have any suggestions on that? For context, here's the issue: github.com/sanzeeb3/wp-frontend-de...

    I have never committed vendor yet, but I'll need to?

  • ☁ Green Panda
    ☁ Green PandaJul 19, 2023

    Try to build and deploy in air gap. oops....

Add comment