1. Your standard library can do it. Whatever you do, RTFM, learn your language inside out and prefer the standard library for whatever you do, even if it looks a little worse — especially if it's not more than 50% more code than using a library for convencience functions. This already goes 80% of the way to prevent "left-pad"-like disasters.
2. Everything that is your core business logic. Don't succumb to the fascination of rule engines and state machine builders. Just write that damn code yourself, future you will be way happier for it.
3. If you're sure that you'll never need more than 10-20% of a library, but eventually will need something considerably different starting from there. This may be grounds for justifying building your own one. If you do that and it doesn't give your business a unique edge, consider open sourcing it from the start.
4. If in doubt, rather stay away from big, fat frameworks until they give you a really big edge (like in Frontend development) or you tend to do a lot of rinse-and-repeat stuff. They tend to solve a lot of your problems, but rot fast and you have to continuously keep up with the Kardashians.
left-pad is a red herring - the problem there was poor dependency management, not the use of the library itself.
> 4. It has traction ie >10k downloads preferably >50k
Why ? Your home-made code probably don't check those boxes.
An unmaintained library is usually more difficult to fix because fixes are no longer committed back or released. At that point you can choose to vendor and maintain your own copy, or replace it with something else. And at either of those points you’re no longer in context.
My point wasn’t really geared at debugging a piece of code. A library, my own, or a coworkers are roughly comparable. The cost to fix is a lot higher in a library though.
It’s not a universal rule, despite the way I originally phrased it.
On the flip side, I have found libraries that are unmaintained and are pleasant enough to understand. I've forked those and used them, happy that:
1. I can quickly fix any bugs that I face
2. Someone else can make use of my maintenance.
The amount of people who uses a product does not determine is quality.
However stars can determine to an extend whether it's a project worth looking at or not.
A mature project that just works does not need new commits.
- If you file a bug report does the bug get fixed? Do you even get a response?
- If you ask for help from the community, do you get it?
Not necessarily whether there are commits or not.
1. It is still alive
2. It is on GitHub so I can easily read the source and look for issues
3. People star it
4. It has traction ie >10k downloads preferably >50k
5. It occupies a name that makes sense ie I’d rather trust using “redux-immutable” than “steel-porcupine”, since it unofficially lends itself to the “vetted one true solution”
6. Then I look at the source quickly and make sure it looks well done under the hood
7. Finally, if it’s particularly confusing, I might run a quick google check to see if there’s blogs about it on the internet explaining how to use the advanced features and check the date on the blogs (1-2 years ago = good, it’s mature)
If any of the above are too dicey and there’s no good options, I put the relevant code in a top level folder called “modules” (or otherwise) with the intention that in the future I might get to delete it if the package ecosystem gets more mature in that space. Sometimes I even get to polish those files up and actually publish them.