Ce qui vous manque, c'est de courir composer install qui importera vos paquets et créera le dossier vendor, ainsi que le script autoload.
Assurez-vous que votre chemin relatif est correct. Par exemple, les scripts d'exemple dans PHPMailer sont dans examples/ sous la racine du projet, de sorte que le chemin relatif correct pour charger l'autochargeur du compositeur à partir de là serait le suivant ../vendor/autoload.php .
Le fichier autoload.php que vous avez trouvé dans C:\Windows\SysWOW64\vendor\autoload.php est probablement une installation globale du compositeur - où vous mettez généralement des choses comme phpcs, phpunit, phpmd, etc.
composer update est pas la même chose, et probablement pas ce que vous voulez utiliser. Si votre code est testé avec les versions actuelles de votre paquetage, l'exécution de la commande update peut provoquer des ruptures qui peuvent nécessiter des travaux et des tests supplémentaires, donc ne courez pas update à moins que vous n'ayez une raison spécifique de le faire et que vous compreniez exactement ce que cela signifie. Pour clarifier davantage - vous ne devriez probablement jamais exécuter composer update localement, jamais sur votre serveur car cela risque de casser les applications en production.
Je vois souvent des plaintes selon lesquelles les gens ne peuvent pas utiliser Composer parce qu'ils ne peuvent pas l'exécuter sur leur serveur (par exemple, parce qu'il est partagé et qu'ils n'ont pas d'accès au shell). Dans ce cas, vous peut Utilisez toujours Composer : exécutez-le localement (dans un environnement qui ne présente pas de telles restrictions) et téléchargez le dossier fournisseur local qu'il génère avec tous vos autres scripts PHP.
Running composer update également effectue un composer install et si vous ne disposez pas actuellement d'un vendor (normal si vous avez un nouveau checkout d'un projet), alors il en créera un, et écrasera aussi tout dossier composer.lock que vous avez déjà, en mettant à jour les versions des paquets qui y sont marquées, et c'est ce qui est potentiellement dangereux.
De même, si vous ne disposez pas actuellement d'un composer.lock (par exemple, s'il n'a pas été commis au projet), alors composer install réalise aussi efficacement un composer update . Il est donc essentiel de comprendre la différence entre les deux car ils sont définitivement pas interchangeables.
Il est également possible de mettre à jour un seul paquet en lui donnant un nom, par exemple :
composer update ramsey/uuid
Cela va résoudre à nouveau la version spécifiée dans votre fichier composer.json et l'installer dans votre dossier de vendeur, et mettre à jour votre composer.lock pour correspondre. Cette méthode est beaucoup moins susceptible de causer des problèmes qu'une méthode générale de vérification de l'identité de l'utilisateur. composer update si vous avez juste besoin d'une mise à jour spécifique d'un paquet.
Il est normal que les bibliothèques pas inclure un composer.lock C'est aux applications qu'il appartient de corriger les versions, et non aux bibliothèques qu'elles utilisent. Par conséquent, les développeurs de bibliothèques doivent assurer la compatibilité avec un plus grand nombre d'environnements hôtes que les développeurs d'applications. Par exemple, une bibliothèque peut être compatible avec Laravel 5, 6, 7 et 8, mais une application qui l'utilise peut avoir besoin de Laravel 8 pour d'autres raisons.
Composer 2.0 (bientôt disponible) devrait supprimer toutes les incohérences restantes entre les résultats des installations et des mises à jour.
1 votes
Cela peut également se produire si vous avez php artisan up ou down dans votre fichier composer.json dans la section scripts de la pré-installation. Il semble avoir besoin de fichiers dans le dossier vendor pour exécuter le mode maintenance, qui n'est pas encore disponible.