Conversation

I think this is key to argument: _small_ deps are the concern, and the putative "harm done" by rewriting a dep (because you don't trust it or simply don't _like_ it -- deps are always a bit of an imperfect fit) is proportional to the dep's size. Big deps matter, but are accepted.
1
6
This Tweet was deleted by the Tweet author. Learn more
It can also be dangerous to reuse code that's poorly implemented or maintained. This is particularly true with cryptography. I often see libraries as a painful compromise because I know I could do a better job if I had the time to invest. Sometimes I can't make that compromise.
2
2
For example, over the years, I've found myself rolling my own sessions for web services, because it's too important to leave it to someone else and I can never find any options doing it up to my standards. It doesn't need cryptography beyond a standard CSPRNG when done right.
1
It depends a lot on the language ecosystem. In some languages, I try to find a library to fit a use case and I can't find anything that's properly maintained or meets my standards. This happens a lot with the traditional Java ecosystem. Each dependency also gives me concern.
1
2
There are currently 2 library dependencies in my projects that are unmaintained. I lack the time to take over maintenance and it's painful to invest the time moving to other libraries. One of these depends on another library that's in a fairly concerning maintenance-only mode.
1
1