22 lines
3.3 KiB
Markdown
22 lines
3.3 KiB
Markdown
---
|
|
name: react-package-selection
|
|
description: Evaluate or recommend dependencies for an existing React application by purpose and project constraints; not source-structure guidance or automatic dependency installation.
|
|
---
|
|
|
|
# React Package Selection
|
|
|
|
Use this workflow when choosing, comparing, or reviewing packages for a React application. It is not a general rule to add dependencies during feature work. Keep package recommendations separate from the `react-structure` skill, which covers source organization.
|
|
|
|
1. Read the active repository's `AGENTS.md` and relevant frontend documentation. Inspect its package manifest, lockfile, package manager, React and TypeScript versions, build tool, existing dependencies, and integration constraints before suggesting additions.
|
|
2. Clarify the purpose and required capabilities. Check whether the existing stack or platform already provides them; prefer no new dependency when it meets the need.
|
|
3. Compare only packages that fit the use case. Evaluate API and React-version compatibility, maintenance and release activity, documentation, accessibility where relevant, security advisories, license, bundle/runtime cost, transitive dependencies, interoperability, testability, and migration or removal cost. Weight criteria according to the project rather than applying a universal score.
|
|
4. Verify current claims using primary sources: package and maintainer documentation, release notes or source repository, package registry metadata, and authoritative security advisories. Browse because package versions, support, and advisories change. Cite the sources for material claims and distinguish verified facts from judgment.
|
|
5. Present a concise comparison organized by purpose, with a recommendation, viable alternatives, tradeoffs, and any unresolved constraints. Do not treat downloads, stars, or familiarity alone as evidence of suitability. Avoid presenting a package as secure or actively maintained without supporting evidence.
|
|
6. Do not change manifests, lockfiles, or install packages as part of an evaluation unless the user asked for implementation. When implementation is requested, follow the repository's package-manager workflow, keep dependency changes scoped, and run its relevant validation.
|
|
|
|
## Package Catalog
|
|
|
|
Use [the React package catalog](references/package-catalog.md) as a starting register of packages reported in deployed applications and optional candidates. It is a discovery aid, not an approved stack or a substitute for project-specific evaluation. Read the catalog when a package decision overlaps its entries; recheck changing claims against current primary sources before relying on them.
|
|
|
|
Keep deployment evidence distinct from package purpose: “Verified” means the package is reported as deployed in a working application. Identify the application and evidence/provenance when known. Separate runtime packages from build, lint, and test tools that support the deployed application but are not shipped to users. Mark unevaluated alternatives “Candidate” and state the concrete use case that would justify review. Add or update entries only when there is a clear React use case; record the review date, constraints, and primary source links for recommendations. Do not turn a candidate into a default or change a project's dependencies without the user's request.
|