Knip : détecter le code mort, les exports inutilisés et les dépendances orphelines dans vos projets TypeScript
TypeScript20 mai 2026·8 min de lecture

Knip : l'outil qui traque le code mort, les exports inutilisés et les dépendances orphelines dans vos projets TypeScript en 2026

Dans tout projet JavaScript ou TypeScript qui prend de l'âge, le code mort s'accumule silencieusement : fichiers jamais importés, fonctions oubliées après un refactoring, dépendances npm qui dorment dans le package.json, variables d'environnement référencées nulle part. Knip s'impose en 2026 comme l'outil de référence pour nettoyer méthodiquement ce gisement de dette technique, là où TypeScript, ESLint et les bundlers s'arrêtent.

Au-delà de TypeScript et ESLint : ce que Knip détecte vraiment

TypeScript et ESLint excellent à analyser un fichier en isolation, mais aucun ne raisonne à l'échelle du projet : ESLint no-unused-vars ne voit pas qu'un export n'est jamais importé ailleurs, et tsc ne distingue pas une dépendance utilisée d'une dépendance fantôme. Knip comble ce vide en construisant un graphe complet de votre code à partir des entry points (vos pages Next.js, votre main.ts Angular, vos scripts CLI), puis en signalant tout ce qui n'est plus atteignable depuis ce graphe. Il détecte les fichiers entiers jamais référencés, les exports nommés inutilisés, les members de classes orphelins, les types et enums isolés, les dépendances npm qui ne sont jamais require ou import, ainsi que les dépendances utilisées mais absentes du package.json. Il va même jusqu'à scanner vos scripts npm et vos variables d'environnement déclarées dans .env pour repérer celles qui n'apparaissent plus dans le code.

Une configuration qui s'adapte à toutes les stacks modernes

La force de Knip tient à ses plugins : plus de 100 intégrations livrées de série pour reconnaître les conventions de Next.js, Nuxt, SvelteKit, Astro, Remix, Vite, Vitest, Playwright, Storybook, ESLint, Prettier, Tailwind, Drizzle, Prisma ou encore Capacitor. Chaque plugin sait identifier automatiquement les entry points implicites du framework (pages, layouts, route handlers, server actions, tests, configurations) et résoudre les chemins comme le ferait l'outil concerné. Pour la majorité des projets, lancer npx knip sans aucune configuration produit déjà un rapport pertinent. Quand un cas particulier échappe à la détection — un fichier consommé uniquement à l'exécution par un script externe, un export utilisé via un import dynamique conditionnel — un fichier knip.config.ts typé permet de déclarer explicitement les entry points additionnels et d'ignorer les faux positifs au cas par cas.

Un mode CI pour empêcher la dette de revenir

Nettoyer une base de code une fois ne suffit pas : sans garde-fou, les exports orphelins reviennent inévitablement à chaque sprint. Knip s'intègre nativement à GitHub Actions et à n'importe quel pipeline CI en sortant un code de retour non nul dès qu'une nouvelle entrée morte est détectée, ce qui bloque le merge tant que la PR n'a pas corrigé ou justifié l'écart. Pour les projets qui démarrent l'adoption au milieu d'une base existante, le mode --include permet de cibler progressivement certaines catégories — uniquement les dépendances inutilisées d'abord, puis les fichiers, puis les exports — afin de découper le nettoyage en plusieurs PRs digestes. Un reporter JSON et un reporter compatible CodeClimate ouvrent la voie à une intégration dans SonarQube, dans un dashboard de qualité interne ou dans un commentaire automatique de PR.

Des gains concrets : bundle plus léger, sécurité renforcée, refactoring plus serein

Les bénéfices d'un passage régulier de Knip se mesurent à plusieurs niveaux. Sur le bundle d'abord : les fichiers et exports morts disparaissent du graphe d'imports, ce qui réduit la taille du JavaScript livré au client et accélère le démarrage des applications React, Vue ou Angular. Sur la sécurité ensuite : chaque dépendance npm encore présente dans le projet est une surface d'attaque potentielle, et supprimer celles qui n'apportent plus rien réduit mécaniquement l'exposition aux vulnérabilités et aux supply chain attacks. Sur la maintenabilité enfin : un développeur qui ouvre un fichier d'utilitaires peut faire confiance à ce qu'il voit, sans craindre de toucher à une fonction "au cas où" elle serait utilisée quelque part. Combiné à TypeScript en mode strict, à Biome ou ESLint pour la qualité du code, et à un linter de dépendances comme npm audit, Knip complète l'arsenal de qualité de code de toute équipe TypeScript exigeante.

Knip n'est ni un linter ni un bundler : c'est un détecteur d'entropie qui rend visible ce que les autres outils laissent invisible. En 2026, l'ajouter au pipeline CI d'un projet TypeScript est l'un des investissements les plus rentables pour préserver la santé d'une base de code sur la durée. Quelques minutes d'analyse hebdomadaire, et la dette technique cesse de s'accumuler sans bruit.

Écrivez-nous