Hey Carles! You demonstrated a firm and relying approach to analyzing existent solutions available on the market npm registry.
I'm thankful that now I have a reasonable article I can share with developers (especially, juniors lacking experience in the matter you explained).
I'd also like to share a few cents from my experience on criteria that are used for selecting a library.
Stars - I suggest weighting this metric as the least important when going through library selection process. People tend to use stars as a sign of popularity and thus a basis that the library can be dependent upon - while popularity and trustworthiness may overlap, the first is not the guarantee of the second.
I would rather recommend relying on a library with only 400 stars having good PR merging trend and up-to-date tests than on a library with 4k stars having a couple of tests altogether and only rare visits to the issues from maintainers.
I believe, Carles implied this in the article but because It didn't get enough attention, I decided to elaborate.
Tests - when selecting a library, check whether there are any tests and whether they are green. You can simply clone the repo and run npm run test. It is not 100% coverage I usually looking here for, but rather a number of tests the prove the main functionality is working (sometimes worth checking on different platforms) and that you can actually read and understand the tests well.
This way (when there are tests and they clearly understandable), you may fix an issue if it is ever found in your project, without discarding the library altogether (which in some cases may require to re-write a lot of code and may cost quite a few resources of your team).
Even if the library maintainers do not respond to the pull request, you can still bring the fork to your company's npm register (if available) or create your scoped npm package (e.g. @your-name/lazysizes).
Hopefully, these few points will be useful to engineers bringing new packages to their projects.
Thanks again for the article, learned quite a few things myself. Never went as far as diving into an engine implementation details myself, but will sure try this out đ
Hey Vitaly thank you so much for your explanation it will be helpful for alot of people too.
Yes, Star number on a repo is not the most important metric to look for when deciding which library should we use but is ok to have a look to it. As a funny history about why stars are not that important... Iâve been working with react for more than five years and I realised THIS YEAR that I wasnât starred the repo yet đâïžđ€Šââïž
Glad to have your feedback Vitaly!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hey Carles! You demonstrated a firm and relying approach to analyzing existent solutions available on
the marketnpm registry.I'm thankful that now I have a reasonable article I can share with developers (especially, juniors lacking experience in the matter you explained).
I'd also like to share a few cents from my experience on criteria that are used for selecting a library.
Stars - I suggest weighting this metric as the least important when going through library selection process. People tend to use stars as a sign of popularity and thus a basis that the library can be dependent upon - while popularity and trustworthiness may overlap, the first is not the guarantee of the second.
I would rather recommend relying on a library with only 400 stars having good PR merging trend and up-to-date tests than on a library with 4k stars having a couple of tests altogether and only rare visits to the issues from maintainers.
I believe, Carles implied this in the article but because It didn't get enough attention, I decided to elaborate.
Tests - when selecting a library, check whether there are any tests and whether they are green. You can simply clone the repo and run
npm run test. It is not 100% coverage I usually looking here for, but rather a number of tests the prove the main functionality is working (sometimes worth checking on different platforms) and that you can actually read and understand the tests well.This way (when there are tests and they clearly understandable), you may fix an issue if it is ever found in your project, without discarding the library altogether (which in some cases may require to re-write a lot of code and may cost quite a few resources of your team).
Even if the library maintainers do not respond to the pull request, you can still bring the fork to your company's npm register (if available) or create your scoped npm package (e.g.
@your-name/lazysizes).Hopefully, these few points will be useful to engineers bringing new packages to their projects.
Thanks again for the article, learned quite a few things myself. Never went as far as diving into an engine implementation details myself, but will sure try this out đ
Hey Vitaly thank you so much for your explanation it will be helpful for alot of people too.
Yes, Star number on a repo is not the most important metric to look for when deciding which library should we use but is ok to have a look to it. As a funny history about why stars are not that important... Iâve been working with react for more than five years and I realised THIS YEAR that I wasnât starred the repo yet đâïžđ€Šââïž
Glad to have your feedback Vitaly!