What you're missing is running composer install
, which will import your packages and create the vendor folder, along with the autoload script.
Make sure your relative path is correct. For example the example scripts in PHPMailer are in examples/
, below the project root, so the correct relative path to load the composer autoloader from there would be ../vendor/autoload.php
.
The autoload.php you found in C:\Windows\SysWOW64\vendor\autoload.php
is probably a global composer installation – where you'll usually put things like phpcs, phpunit, phpmd etc.
composer update
is not the same thing, and probably not what you want to use. If your code is tested with your current package versions then running update
may cause breakages which may require further work and testing, so don't run update
unless you have a specific reason to and understand exactly what it means. To clarify further – you should probably only ever run composer update
locally, never on your server as it is reasonably likely to break apps in production.
I often see complaints that people can't use composer because they can't run it on their server (e.g. because it's shared and they have no shell access). In that case, you can still use composer: run it locally (an environment that has no such restrictions), and upload the local vendor folder it generates along with all your other PHP scripts.
Running composer update
also performs a composer install
, and if you do not currently have a vendor
folder (normal if you have a fresh checkout of a project), then it will create one, and also overwrite any composer.lock
file you already have, updating package versions tagged in it, and this is what is potentially dangerous.
Similarly, if you do not currently have a composer.lock
file (e.g. if it was not committed to the project), then composer install
also effectively performs a composer update
. It's thus vital to understand the difference between the two as they are definitely not interchangeable.
It is also possible to update a single package by naming it, for example:
composer update ramsey/uuid
This will re-resolve the version specified in your composer.json
and install it in your vendor folder, and update your composer.lock
file to match. This is far less likely to cause problems than a general composer update
if you just need a specific update to one package.
It is normal for libraries to not include a composer.lock
file of their own; it's up to apps to fix versions, not the libraries they use. As a result, library developers are expected to maintain compatibility with a wider range of host environments than app developers need to. For example, a library might be compatible with Laravel 5, 6, 7, and 8, but an app using it might require Laravel 8 for other reasons.
Composer 2.0 removed any remaining inconsistencies between install and update results; if you're running composer 1.x you should definitely upgrade.