Installing a package can turn hours of work into a one-line command. The immediate convenience is visible; the future responsibility is not. Every dependency introduces code, update decisions and trust in people outside the project.
Begin by asking whether the dependency is necessary. A small and stable function may be simpler to implement locally. A complex parser, cryptographic library or framework is different: using a well-reviewed project is usually safer than creating a private replacement.
Examine maintenance activity, but do not confuse frequent commits with quality. Mature software may change slowly. More useful signals include clear release notes, responsive handling of security reports, documented support policy and multiple trusted maintainers.
Review the dependency tree. A tiny package can pull in dozens of transitive packages, each with its own maintainers and risks. Lockfiles improve repeatability, but they do not remove the need to understand updates.
Check the license before adoption. A technically excellent library may impose conditions that do not fit the project’s distribution model. Legal review becomes more important for commercial software and embedded products.
Finally, define an exit strategy. Know which parts of the application depend on the package and avoid spreading library-specific assumptions everywhere. A dependency is easier to replace when it sits behind a clear internal interface.