# In·dépendance

> [en] I read a lot of other people’s code. I highly recommend it. One of my golden rules is that you shouldn’t blackbox things you don’t need to. I like to ==“use dependencies for efficiency, not ignorance.”==
>
> When I’m vendoring code - copying it into the project and making it pass my basic eslint & testing standards, I’ll do light rewrites and refactors of new code, allowing me to get a deeper understanding of how they work and where their limits lie.
>
> […]
> 
>
> And sometimes, sure - I’ll read through a dependency, start refactoring, and realize that it’s going to be simpler to write it myself, or I should find another option. It doesn’t matter if something is a dependency or my code: when you ship a product, it’s all your responsibility.
>
> <cite>*[Vendor by default](https://macwright.com/2021/03/11/vendor-by-default.html)* ([cache](/david/cache/2021/4b81d4d9d89fb1d417aa292463529271/))</cite>

C’est l’une des raisons pour lesquelles j’essaye d’aller le plus loin possible avec un produit sans avoir de système de dépendances JS autre que la récupération du *build* qui est présent sur le dépôt source (s’il n’y en a pas, tant pis…). Le fait de copier manuellement ce fichier sur mon propre dépôt donne du poids à la dépendance, ce n’est pas une simple ligne dans un fichier. Un effet de bord que j’apprécie beaucoup aussi est de pouvoir identifier et corriger les *bugs* localement plus facilement.

Cela me rappelle les pistes que [j’explorais déjà il y a 5 ans](/david/blog/2016/simplicite-defaut/), notamment la partie sur les budgets.