5 ms·

The list seems to be overly reliant on GitHub stars as the main metric for measuring if a library is worth considering or not. I wrote a checklist with some qu

The list seems to be overly reliant on GitHub stars as the main metric for measuring if a library is worth considering or not. I wrote a checklist with some questions that can help you find potential issues with third party packages: - [ ] Is the package licensed in a way you can use? - [ ] Is the package's latest published version free of known security vulnerabilities? (can check with https://snyk.io/vuln/npm:moment https://snyk.io/vuln/npm:moment) - [ ] Is the package tested? (there need to be at least some unit tests) - [ ] Is the package lightweight? (can check with https://bundlephobia.com/ https://bundlephobia.com/, this should be considered alongside the size of the problem being solved) - [ ] Is the package dependant on no other packages? (0 dependencies = less to worry about) - [ ] Is the package maintained? (activity in the last year, don't forget to check branches other than master) - [ ] Is the package popular and widely used? (depended on by lots of other projects, number of stars on GitHub) - [ ] Is the package well structured and easy to understand? (could you contribute and make changes to it quickly? you may have to!) Once you do decide to adopt something, it's a good pattern to only import it in one place (like an internal `helper` library) and to reference that in every part of the codebase where it's needed. This is in case you decide to replace it in the future, so you only have to change one place.

motdiem 8y ago
That's a great checklist - I'll add to that that it's always a good idea to give a cursory glance at the source code. For the "is it maintained" part, I like to look at issues and how they are resolved
- yoz-y 8y ago
  It is also useful to see how many point releases they do or if their idea of maintenance is rewriting the whole thing every time somethings comes up.
michaelmior 8y ago
> don't forget to check branches other than master Curious what the thinking is on this. It's true that development could be happening on a branch other than master, but if that's the case I would expect that to be set as the main branch. Maybe master is used only for releases, but that's still a good way to check activity.
- tvararu 8y ago
  My thinking is that commonly activity on master halts for months/years because a v.NEXT is being worked on, so it's worth checking if that's the case and whether it's worth waiting for the new version or adopting the alpha/beta.
  - michaelmior 8y ago
    Fair point. That does happen sometimes :)

motdiem 8y ago

That's a great checklist - I'll add to that that it's always a good idea to give a cursory glance at the source code. For the "is it maintained" part, I like to look at issues and how they are resolved

yoz-y 8y ago
It is also useful to see how many point releases they do or if their idea of maintenance is rewriting the whole thing every time somethings comes up.

michaelmior 8y ago

> don't forget to check branches other than master Curious what the thinking is on this. It's true that development could be happening on a branch other than master, but if that's the case I would expect that to be set as the main branch. Maybe master is used only for releases, but that's still a good way to check activity.

tvararu 8y ago
My thinking is that commonly activity on master halts for months/years because a v.NEXT is being worked on, so it's worth checking if that's the case and whether it's worth waiting for the new version or adopting the alpha/beta.
- michaelmior 8y ago
  Fair point. That does happen sometimes :)