In·dépendance

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.

Vendor by default (cache)

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, notamment la partie sur les budgets.