Désencombrer les dépôts clients

Table des matières

Knip

Knip est utile pour identifier les dépendances non répertoriées, les exports dupliqués et les fichiers, dépendances ou exports potentiellement inutilisés.

Attention aux faux positifs !

Évitez d’implémenter aveuglément tout ce qui est signalé. Regardez, vérifiez et testez. Faites vos propres recherches et réflexions pour des éléments comme les exports signalés comme inutilisés.

Knip n’est pas destiné à resource-core, webfonts-core, pankosmia-web ou desktop-app-*.

Il est destiné aux projets construits avec un packages.json et un index.js, qu’il utilise pour parcourir et évaluer tous les includes de l’application.

Configuration

npm install -g knip (pour installer ou mettre à jour)

Analyser un dépôt

À la racine du dépôt client dans un terminal, saisissez knip. Il fournira une liste de tous les éléments inutilisés, non répertoriés ou dupliqués qu’il pense avoir trouvés.

Exemple de faux positifs sur les exports inutilisés

Il signalera Selection.styles.jsx comme un export inutilisé (à cause du nom de fichier) même lorsqu’il est utilisé. Veillez à ne pas supprimer ce fichier lorsque son export est réellement utilisé.

Exemple d’exports signalés comme dupliqués ne posant en réalité aucun problème

Selection.styles.jsx exporte sx, ce qui fonctionne parfaitement tel qu’utilisé.

Exemple de faux positif sur les dépendances inutilisées

Knip est plutôt bon pour suivre la chaîne d’includes à travers un projet. Cependant, il arrive que des dépendances soient en place en dehors de cette chaîne, ce qu’il ne détectera pas. Par exemple, si un package.json utilise react-scripts dans sa section scripts, sa chaîne de dépendances inclut babel, qui inclut une devDependency @babel/plugin-proposal-private-property-in-object. Knip manquera ce cas et le signalera comme une dépendance inutilisée, alors qu’en réalité elle est bien utilisée.

Appliquer les modifications de paquets tout en gardant les installations locales propres et cohérentes

  • Utilisez npm ci. Cela supprime node_modules et correspond au fichier de verrouillage.
  • Pour mettre à jour la version d’un paquet, faites suivre npm ci de npm install <package_name>@0.1.29 --save-exact
  • Pour supprimer un paquet, faites suivre npm ci de npm uninstall <package_name>
  • Pour ajouter un paquet, faites suivre npm ci de npm install <package_name> --save-dev ou npm install <package_name> -D (pour les devDependencies) ou npm install <package-name> --save-optional

Pourquoi éviter de modifier manuellement package.json (sauf lorsque c’est impossible) ?

npm i tend à créer des différences de package-lock.json selon le système d’exploitation et ne garde pas node_modules propre. Notez également qu’après une modification manuelle de package.json, l’exécution de npm prune ne met pas à jour package-lock.json pour refléter la suppression, et ne désinstalle pas les scripts de cycle de vie (qui permettent aux paquets d’effectuer automatiquement des actions personnalisées).