3 ms·

I didn't read through all the article, but I am not convinced. Vendoring isn't scalable for the long term. Everytime you want to use a dependency, you will have

I didn't read through all the article, but I am not convinced. Vendoring isn't scalable for the long term. Everytime you want to use a dependency, you will have the overhead of first understanding the code and then copy-paste. The dividends might be there, but not worth it.

xyzzy123 4y ago
I don't think it's kind to maintainers. IMHO vendoring all the things works for very small (personal) projects or for very large projects (you are google), but not for most of the stuff in between. It's great to be the sort of developer who reads all their dependencies, what's not nice is forcing maintainers to do that too after you have left - we usually want to expend the minimum effort necessary to keep your application vulnerability-free and still-deployable and do not appreciate "artisanal" takes. I want to see locked dependency versions and use of company artefact repositories to avoid unexpected changes and avoid availability concerns (e.g. it gets yanked off npm or github etc). I am not pleased to find vendoring, as I now have to work out what (if any) code has been changed, what version of the upstream it corresponds to, and I now have to potentially merge third party code to do otherwise simple updates. How bad this all is depends on the language and style of vendoring. The absolute worst case is when someone like the author has vendored everything, deleted half of it, pointlessly eslinted it(!) made a few cosmetic changes here and there, ... "haha good luck merging from upstream now" - it adds no business value but increases maintenance costs. Depending on tooling, I may now also have to commit to periodic manual review for dep based CVEs instead of just letting the company dep scanner sort those out. I have no problems with vendoring "for the right reasons" e.g. if you actually needed to change the code to fix a bug or make a change that's fairly specific to your application.

xyzzy123 4y ago

I don't think it's kind to maintainers. IMHO vendoring all the things works for very small (personal) projects or for very large projects (you are google), but not for most of the stuff in between. It's great to be the sort of developer who reads all their dependencies, what's not nice is forcing maintainers to do that too after you have left - we usually want to expend the minimum effort necessary to keep your application vulnerability-free and still-deployable and do not appreciate "artisanal" takes. I want to see locked dependency versions and use of company artefact repositories to avoid unexpected changes and avoid availability concerns (e.g. it gets yanked off npm or github etc). I am not pleased to find vendoring, as I now have to work out what (if any) code has been changed, what version of the upstream it corresponds to, and I now have to potentially merge third party code to do otherwise simple updates. How bad this all is depends on the language and style of vendoring. The absolute worst case is when someone like the author has vendored everything, deleted half of it, pointlessly eslinted it(!) made a few cosmetic changes here and there, ... "haha good luck merging from upstream now" - it adds no business value but increases maintenance costs. Depending on tooling, I may now also have to commit to periodic manual review for dep based CVEs instead of just letting the company dep scanner sort those out. I have no problems with vendoring "for the right reasons" e.g. if you actually needed to change the code to fix a bug or make a change that's fairly specific to your application.