[alloy]

> This is kind of the opposite of the standard advice of "don't repeat yourself" and "don't reinvent the wheel". Both those pieces of advice make an awful lot of sense to me.

It’s not about re-implementing everything per project, it’s a reminder to think about all of the code you pull into your project.

We use some third-party gems, we have our own gems, but as a rule these should all provide the minimum necessary and not try to solve all higher-level use-cases. Because these types of libs, that do come with the proverbial kitchen-sink, tend to bring in functionality that you won’t be using but are still very much opportunities for bugs.

> You shouldn't have to be thinking about its inner workings. Some gems really can carry big risks with them.

Some might indeed carry big risks, which is why it’s good to know your code and that is made significantly easier with less code.

However, you should be thinking about their inner workings. Especially, but not limited to, open-source code which all (afaik) provide no warranty whatsoever. So when you pull it in, directly or indirectly, you are responsible.