dependency-selectionlisted

# Dependency Selection A dependency is a permanent liability accepted for a temporary convenience. Sometimes that trade is excellent. It is never free, and it is never reversed casually. ## 1. The three questions before the evaluation Asked in order. Two of them end the discussion most of the time. 1. **Does the project already solve this?** Search the codebase and the installed tree. Adding a second date library, a second HTTP client, a second validation library or a second state manager is a defect. 2. **Does the platform solve this?** Standard library, runtime API, framework feature. Many dependencies exist because they predate a platform feature that now ships everywhere the project runs. 3. **Is the problem small enough to own?** Fifty lines the team understands beat a package with nine transitive dependencies for a formatting helper. The inverse is also true: cryptography, date arithmetic across timezones, parsers and accessibility primitives are not written by hand. ## 2. The twelve point evaluation Applied only to candidates that survive section 1. | # | Criterion | Reject when | |---|---|---| | 1 | solves the actual need | it solves a superset and the excess is most of the cost | | 2 | framework and runtime compatibility | it needs a version the project cannot adopt | | 3 | maintenance | no release or no answered issue in a long period, single maintainer with no succession | | 4 | security | known unfixed advisories, or a history of slow r