Supprimer un package Laravel avec Composer : guide complet

Introduction : pourquoi le « bazar » dans un projet est nuisible, et comment Composer aide à le nettoyer

Avez-vous déjà remarqué comment un projet Laravel se transforme peu à peu en un gigantesque dépôt de packages inutiles ? Vous en avez installé un pour un prototype, un autre pour une expérience, un troisième « au cas où ». Puis le projet vit, évolue, et ces packages restent comme un poids mort, gonflant le dossier vendor et ralentissant composer install.

Tôt ou tard, chaque développeur se pose la question : « Comment supprimer un package de Laravel avec PHP Composer ? ». Et ce n'est pas qu'une simple opération technique — c'est tout un art de remettre de l'ordre. Aujourd'hui, nous allons décortiquer ce processus de A à Z : pas seulement les commandes, mais un cycle complet de nettoyage avec des exemples, des astuces et l'analyse des pièges classiques.

Prêt à transformer votre projet de « décharge de dépendances » en un système bien structuré ? C'est parti !

Ce qu'il faut savoir avant de supprimer un package

Avant de lancer composer remove, comprenons comment Composer gère les dépendances. Dans Laravel (et tout projet PHP), Composer fonctionne avec deux fichiers principaux :

\n
• composer.json — la liste de tous les packages requis et leurs versions.
\n
• composer.lock — un instantané précis des versions installées, pour que le projet fonctionne à l'identique sur toutes les machines.
\n

Lorsque vous supprimez un package, Composer met à jour les deux fichiers : il retire l'entrée de composer.json et recalcule composer.lock sans la dépendance supprimée. Mais attention : si le package est utilisé par d'autres packages, Composer refusera de le supprimer. Un outil intelligent, on ne peut pas dire le contraire.

La commande principale : composer remove

La façon la plus simple et la plus correcte de supprimer un package est d'utiliser la commande intégrée composer remove. La syntaxe est très simple :

composer remove vendor/package-name

Par exemple, si vous souhaitez supprimer le célèbre package de débogage barryvdh/laravel-debugbar, la commande sera :

composer remove barryvdh/laravel-debugbar

Après exécution, vous verrez un résultat similaire à celui-ci :

Package "barryvdh/laravel-debugbar" removed from require\nLoading composer repositories with package information\nUpdating dependencies (including require-dev)\nNothing to install or update\nGenerating optimized autoload files\n

Et voilà ! Le package a disparu de vendor, de composer.json et de composer.lock. Mais ce n'est que le début. La vraie magie opère lorsque vous commencez à nettoyer le projet de ses « résidus ».

Suppression des dépendances de développement

Si le package a été installé uniquement pour le développement (par exemple, phpunit/phpunit), il est généralement listé dans la section require-dev. Composer sait d'où le supprimer, mais pour être sûr, vous pouvez utiliser l'option --dev :

composer remove --dev phpunit/phpunit

Cela garantit que la commande s'applique spécifiquement aux dépendances de développement. En pratique, Composer s'en sort très bien même sans cette option.

Suppression manuelle : quand l'automatisation ne suffit pas

Il existe des situations où composer remove refuse de fonctionner. Par exemple, si le package est une dépendance d'un autre package que vous ne supprimez pas. Ou si vous avez accidentellement supprimé une entrée de composer.json manuellement, alors que le package est toujours dans vendor.

Dans ces cas, il faut agir de manière plus radicale. Voici l'algorithme de suppression manuelle :

\n
1. Supprimez l'entrée du package dans la section require ou require-dev du fichier composer.json.
\n
2. Supprimez le dossier du package dans vendor/vendor/package-name (vous pouvez aussi supprimer tout le dossier vendor — mais c'est radical).
\n
3. Lancez composer updat