Évaluation avant ajout d'une nouvelle dépendance. Se charge sur : npm install <pkg>, npm add <pkg>, yarn add <pkg>, pnpm add <pkg>, bun add <pkg>, pip install <pkg>, poetry add <pkg>, uv add <pkg>, composer require <pkg>, cargo add <crate>, go get <pkg>, gem install <pkg>, ou édition manuelle de package.json, requirements.txt, pyproject.toml, composer.json, Cargo.toml, go.mod, Gemfile. Vérifie : solution native possible, taille du package, maintenance (last release, open issues, stars), licence, alternative plus légère, impact sécurité. Ne se charge PAS quand : mise à jour (npm update, composer update), suppression, audit, ou discussion de dépendances déjà installées.

Dependency Check — Évaluation avant ajout

Ce skill s'active quand une nouvelle dépendance est sur le point d'être ajoutée au projet.

Questions obligatoires

Avant d'ajouter une dépendance, répondre à :

C'est nécessaire ? — Le langage/framework ne fournit-il pas déjà cette fonctionnalité nativement ?
Une seule utilisation ? — Si on l'utilise à un seul endroit, 10-20 lignes de code maison suffisent-elles ?
Alternative plus légère ? — Existe-t-il un package plus petit qui fait le strict nécessaire ?
Activement maintenu ? — Dernière release, issues ouvertes, nombre de contributeurs
Impact sur le bundle ? — Taille, tree-shaking possible ?

Ordre de préférence

1. Natif (stdlib, API du langage/framework)
   ↓ pas disponible
2. Dépendance établie (>10k stars, maintenance active, écosystème large)
   ↓ trop lourde
3. Dépendance légère (focalisée, peu de sous-dépendances)
   ↓ pas trouvée
4. Code custom (documenté, testé)

Signaux d'alerte

Signal	Risque
Pas de release depuis >1 an	Abandon potentiel
Beaucoup d'issues ouvertes sans réponse	Maintenance faible
Trop de sous-dépendances	Surface d'attaque large
Pas de types TypeScript	Intégration difficile
Licence restrictive (GPL dans un projet MIT)	Incompatibilité
Package qui fait "tout"	Over-engineering importé

Exemples courants

Souvent inutile

On ajoute...	Alors que...
`lodash` (entier)	`lodash/get` ou natif (`?.`, `.flat()`, `.map()`) suffit
`moment`	`Intl.DateTimeFormat` ou `date-fns` (tree-shakable)
`axios`	`fetch` natif suffit dans la plupart des cas
`uuid`	`crypto.randomUUID()` est natif
`left-pad`	C'est une ligne de code
`is-odd`	`n % 2 !== 0`

Souvent justifié

Dépendance	Pourquoi
`zod` / `joi`	Validation de schemas — complexe à réimplémenter correctement
`bcrypt` / `argon2`	Crypto — ne JAMAIS réimplémenter soi-même
ORM (`prisma`, `drizzle`)	Requêtes typées, migrations, sécurité SQL
Framework de test (`vitest`, `jest`)	Infrastructure de test complète

Par écosystème

npm (JavaScript / TypeScript)

Souvent évitable	Alternative native ou légère
`lodash`	Natif ES2024+ (`.structuredClone()`, `?.`, `Object.groupBy()`)
`moment` / `dayjs`	`Intl.DateTimeFormat`, `Temporal` (stage 3)
`axios`	`fetch` (natif Node 18+, navigateurs)
`uuid`	`crypto.randomUUID()`
`dotenv`	`--env-file` (Node 20+)
`node-fetch`	`fetch` natif (Node 18+)
`chalk`	`util.styleText()` (Node 21+)

pip (Python)

Souvent évitable	Alternative
`requests` (pour du simple)	`urllib.request` (stdlib) ou `httpx` (async)
`python-dotenv`	`os.environ` + `.env` dans le runner
`arrow`	`datetime` (stdlib)
`six`	Python 3 natif

composer (PHP)

Souvent évitable	Alternative
`guzzlehttp/guzzle` (simple)	`file_get_contents` + `stream_context` ou `curl`
`nesbot/carbon` (basique)	`DateTimeImmutable` natif
`illuminate/support` (hors Laravel)	Fonctions natives PHP 8+
`ramsey/uuid`	`random_bytes()` + format UUID

Comportement

Proposer un défaut — toujours recommander la solution la plus légère (natif > lib établie > lib légère > custom) avec une alternative si le défaut ne convient pas
Signaler quand une dep semble évitable — proposer l'alternative
Ne pas bloquer si l'utilisateur a fait son choix consciemment
Vérifier la compatibilité de licence avec le projet
Si ajout justifié → s'assurer que la dep est dans CLAUDE.md section "Dépendances clés"

dependency-check