This skill is used when adding, replacing, or reviewing library or package dependencies in this repository.
Basic Policy
Choose dependency libraries with priority on reliability and the prospect of continued maintenance.
First check whether the standard library, existing dependencies, or the official features of the framework in use are sufficient. When adding a new dependency, limit it to the scope necessary and sufficient for the purpose.
Preferred Dependencies
Prefer the following kinds of dependencies.
- Those provided by reliable organizations or vendors such as Microsoft, Meta, Google, Apple, Amazon, Cloudflare, OpenJS Foundation, etc.
- Official packages of the framework or runtime in use
- Those already adopted in this repository with no problems in maintenance status
- Those widely used for that purpose and that can be described as the de facto standard compared with alternative candidates
Dependencies to Basically Avoid
Basically exclude the following dependencies from consideration.
- Libraries maintained solely by an individual developer
- Libraries with fewer than 1000 GitHub stars
- Libraries with weak recent maintenance status, issue response, or release frequency
- Small convenience libraries that merely replace trivial processing
- Libraries with a large dependency tree that are excessive for the purpose
Conditions That Can Be Allowed as Exceptions
Even if it is individual development or has fewer than 1000 stars, it can be a candidate if there is the following backing.
- It is treated as the de facto standard for that purpose
- There are examples of adoption in major frameworks, official documentation, or large-scale projects
- No alternative official or major-vendor library exists
- Maintaining the implementation in-house would greatly increase the risks to maintainability, security, and compatibility
When adopting as an exception, leave the reason for adoption (positive Why) in the commit log. In code comments, write only the Why not, such as the reason for rejecting alternative means or preventing mistaken changes.
// HEIC 変換に公式の軽量実装はなく、自前実装へ戻すとフォーマット差分の保守コストが増えるため sharp を使う。
import sharp from "sharp";
Investigation Procedure
Before adding a dependency, check the following.
- Whether it cannot be replaced by standard features, existing dependencies, or official APIs.
- Whether the package provider is an organization or an individual.
- Whether GitHub stars are 1000 or more.
- The status of the last release, issues, pull requests, and security advisories.
- Adoption track record in major projects or official documentation.
- Whether the dependency tree, bundle size, and license are appropriate for the purpose.
Because stars, maintenance status, and adoption track record change, check the current information when deciding to newly add a dependency.
Handling During Review
When reviewing dependency additions or replacements, check the following.
- Whether processing that could be handled by official features or existing dependencies has been made into a new dependency
- Are you prioritizing reliable vendors and official packages?
- Are you avoiding dependencies that are individually developed or have fewer than 1000 stars?
- In the case of an exceptional adoption, is there evidence that it is a de facto standard?
- In the case of an exceptional adoption, is the reason for adoption (positive Why) recorded in the commit log?
- In the case of an exceptional adoption, is a Why not comment (rejection of alternative means, prevention of erroneous changes) recorded at the implementation site?
package.json If the dependency is only visible in files where comments cannot be written, such as, leave a Why not at the implementation site that directly uses that dependency, and record the reason for adoption in the commit log.