Vendoring means taking it one step further: you commit all your dependencies’ source code into your own repo so the act of cloning the project gets you literally everything.
Forking is when you make a clone of a git repository, so you would check out a copy of the source code from your dependencies’ repository, and then push them as their own repositories to Codeberg or wherever.
Vendoring is taking the result of your dependency installation, like your node_modules folder, and checking it in to your own repository. So, instead of 15 or whatever repositories with other folks’ source code, you have just one repository with the built libraries checked in.
The benefit to forking is you can rebuild from source if you so choose, but the Vendoring means taking it one step further: you commit all your dependencies’ source code into your own repo so the act of cloning the project gets you literally everything. is it’s a lot of repos to keep track of. The benefit to forking is you just reinstall the dependencies and check in the result, but the downside is your single repository is huge and takes forever to clone.
This does appear to then break the chain of trust for the users of the project, since it then requires downstream to review even more code.
For example, if you’re an OSS user of three projects that each depend on library X, you now need to trust three copies of this library and make sure that they’re the same as the original.
This seems to be a solution that makes the problem bigger for everyone, not smaller.
I suppose? You’re either reviewing your dependencies or you’re not; I don’t think it matters much whether the unreviewed code comes in via a commit to your git repo or via a package manager. Once you’ve decided to either vendor or fork, that it matches your upstream becomes much less important — what matters is it works for your project. Either approach definitely comes with tradeoffs, that’s for sure; I only fork when I need to float a commit, and I prefer to maintain an artifactory if high availability is required.
In hindsight, I question the wisdom of my decision to respond to this thread at 2 am my time 😅. Thanks for being nice even though my responses were borderline incoherent.
Based on the description from the article
Forking is when you make a clone of a git repository, so you would check out a copy of the source code from your dependencies’ repository, and then push them as their own repositories to Codeberg or wherever.
Vendoring is taking the result of your dependency installation, like your node_modules folder, and checking it in to your own repository. So, instead of 15 or whatever repositories with other folks’ source code, you have just one repository with the built libraries checked in.
The benefit to forking is you can rebuild from source if you so choose, but the Vendoring means taking it one step further: you commit all your dependencies’ source code into your own repo so the act of cloning the project gets you literally everything. is it’s a lot of repos to keep track of. The benefit to forking is you just reinstall the dependencies and check in the result, but the downside is your single repository is huge and takes forever to clone.
So … using a dependency as a submodule?
You could do it as submodules, yeah, or using lfs, or also just check in the deps without their corresponding git history.
This does appear to then break the chain of trust for the users of the project, since it then requires downstream to review even more code.
For example, if you’re an OSS user of three projects that each depend on library X, you now need to trust three copies of this library and make sure that they’re the same as the original.
This seems to be a solution that makes the problem bigger for everyone, not smaller.
I suppose? You’re either reviewing your dependencies or you’re not; I don’t think it matters much whether the unreviewed code comes in via a commit to your git repo or via a package manager. Once you’ve decided to either vendor or fork, that it matches your upstream becomes much less important — what matters is it works for your project. Either approach definitely comes with tradeoffs, that’s for sure; I only fork when I need to float a commit, and I prefer to maintain an artifactory if high availability is required.
I meant the users of your project.
In hindsight, I question the wisdom of my decision to respond to this thread at 2 am my time 😅. Thanks for being nice even though my responses were borderline incoherent.
No worries, it’s 3am here right now 😁