vendeesign

dependency-check

"Évaluation automatique avant l'ajout d'une dépendance. Activer quand : Claude s'apprête à exécuter npm/yarn/pnpm install, pip install, composer require, cargo add, ou go get ; OU quand un import/require pointe vers un package non encore installé ; OU quand l'utilisateur demande d'ajouter une lib. Pose les bonnes questions : natif possible ? Taille ? Maintenance ? Alternative plus légère ? Ne pas activer si la dépendance est déjà installée dans le projet (présente dans package.json/composer.json/requirements.txt), ni pour les devDependencies de test (vitest, jest, pytest) sauf si l'utilisateur demande un avis."

vendeesign 3 1 Updated 2mo ago
GitHub

Install

npx skillscat add vendeesign/codebloom/dependency-check

Install via the SkillsCat registry.

SKILL.md

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 à :

  1. C'est nécessaire ? — Le langage/framework ne fournit-il pas déjà cette fonctionnalité nativement ?
  2. Une seule utilisation ? — Si on l'utilise à un seul endroit, 10-20 lignes de code maison suffisent-elles ?
  3. Alternative plus légère ? — Existe-t-il un package plus petit qui fait le strict nécessaire ?
  4. Activement maintenu ? — Dernière release, issues ouvertes, nombre de contributeurs
  5. 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

  • 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"