Picking a library

Picking a library for a project might not be as simple as just googling and picking something stated in StackOverflow. We need to be extremely careful as any bad decision might lead to bugs, maintenance related issues or even security bugs.

Before deciding to add a new library, please follow this steps:

  1. Check if it's not already being used in our base projects.
  2. Ask over #dev channel if any team requires the same functionality as you do.
  3. If non of the before mentioned steps are successful, then look for a new library.
  4. Ask for guidance in #dev or any technical leader before deciding. Remember to be clear and add context to your question when asking. If library is too complex, even a Request for comments file might be needed.
  5. Try to get the library included in the base project or in Awesome Atix so it can be part of our knowledge base.

Warning

Don't forget to check library source code. It might happen that it's just a convenience wrapper over a standard lib and might worth introducing it. Check out this example.

How to pick a library?

The following guide was taken from here and contains a really good set of rules that you should present when deciding for a library. Ideally a table containign the following evaluation items should be presented to compare the alternatives:

  1. Available options: Start by pulling together as many options as you can.

    • Use google but most of the interesting libraries are on Github or Gitlab.
    • Be careful when spending time looking for a library. Avoid falling into a rabbit hole.

  2. Popularity: A popular project on GitHub means exactly what you expect it to. Namely, that there are lots of people questioning, contributing and supporting it. This activity tends to result in more reliable software. You can check the popularity of any project by looking at how many stars it has, how many issues are opened, how many pull requests are pending, and how many contributors worked on the project.

    • Look for projects with several stars or likes.
    • Don't forget to check if issues make sense and are properly answered by maintainers.

  3. Maintenance: Software becomes dated and buggy when not maintained.

    • A nice proxy for this is to check when the last commits were made. If this was 4 years ago, I would go with another option.

  4. Users: Some projects are backed by big players who will have a vested interest in ensuring the project is maintained.

    • Look for supporters section
    • Check if any real-life project is mentioned amongst is users.

  5. Tests: A really well-tested project counts for a lot. It not only implies that the software does what it’s supposed to do, but also that the developer themselves has a rigorous methodology.

    • Look for well and properly documented tests. Check if they are useful.
    • This will be no wasted time as most of the time the tests will help you understand how the library should be used.
    • A project without tests or poorly written ones is a red flag.

  6. Downloads: Many package managers share their download statistics. For example, if you want to check the statistics related to an npm package, you can go to https://www.npmjs.com/package/name-of-package to see the stats.