Désencombrer les dépôts clients

Table des matières

• Knip
  • Configuration
  • Analyser un dépôt
  • Exemple de faux positifs sur les exports inutilisés
  • Exemple d’exports signalés comme dupliqués ne posant en réalité aucun problème
  • Exemple de faux positif sur les dépendances inutilisées
• Appliquer les modifications de paquets tout en gardant les installations locales propres et cohérentes

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 ou npm install --global 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

Migration de npm vers pnpm en cours

Utilisez le fichier de verrouillage à la racine du dépôt pour déterminer lequel s’applique : pnpm-lock.yaml → pnpm ; package-lock.json → npm. Pour plus de détails, consultez notre Plan de migration.

	pnpm-lock.yaml	package-lock.json
Utilisez	pnpm install ou modifiez manuellement package.json puis exécutez pnpm i	npm ci. Cela supprime node_modules et correspond au fichier de verrouillage.
Pour mettre à jour la version d’un paquet, faites suivre pnpm i/npm ci de :	pnpm i <package_name>@0.1.29 --save-exact ou modifiez manuellement package.json puis exécutez pnpm i	npm i <package_name>@0.1.29 --save-exact
Pour supprimer un paquet, faites suivre npm ci de :	pnpm uninstall <package_name> ou modifiez manuellement package.json puis exécutez pnpm i	npm uninstall <package_name>
Pour ajouter un paquet, faites suivre pnpm i/npm ci de :	pnpm i <package_name> --save-dev ou pnpm i <package_name> -D (pour les devDependencies) ou pnpm add <package-name> -O ou modifiez manuellement package.json puis exécutez pnpm i	npm i <package_name> --save-dev ou npm i <package_name> -D (pour les devDependencies) ou npm i <package-name> --save-optional