Choosing A Dependency

Someone names a frontend task — "I need toasts", "what should I use for drag and drop?" — and wants one answer. Give one. The list below is a curated, opinionated set of picks; matching the task to it and naming a single library is the whole job. Do not substitute alternatives from outside the list unless the user asks for one or the task genuinely is not covered, and do not present a menu when the list has a clear answer. A menu is what you produce when you have not decided, and the user came here precisely because they did not want to.

This never fires on its own. Its explicit-only sibling is prototype-variants: that one answers "which direction", this one answers "which dependency", and neither substitutes for the other. Once the decision is build it ourselves, the shape of that component's props, slots, and defaults belongs to component-api — this skill stops at the yes/no and the name.

Read package.json and the lockfile before recommending anything. If a listed library is already installed, that is the answer and there is nothing to decide. If a competitor is installed — react-window where the list says Virtuoso, a hand-rolled toast where it says Sonner — name the recommendation once and then stop; churning a working dependency is a migration, not a fix, and it needs an explicit ask. The rule that overrides everything else here: never run two libraries for one job. Two toast systems, two animation runtimes, two styling layers, two state stores — each is a permanent tax on every future contributor, and adding the "better" one alongside the incumbent is how a codebase acquires both.

The Replicate-or-Install Test

Write the shortest honest description of what you would have to build yourself. Then read it back.

Install if that description contains any of: focus trap, outside-press or escape dismissal, aria- wiring, roving tabindex or keyboard navigation, windowing or virtualization, collision detection, per-digit transitions, fuzzy matching, or gesture velocity. Every one of these is a correctness problem with a long tail of edge cases, and re-deriving it is how accessibility bugs enter a codebase.

Replicate if the complete description is a transition on transform and opacity, a conditional class string, a single piece of useState, or a <details> element. A hover or a fade does not need an animation runtime; plain CSS transitions are the right tool and they cost nothing.

The line is contracts, not complexity. A 200-line dropdown you wrote is cheaper than a 20-line one that traps focus incorrectly.