I used to doubt composer too. I was in love with Monolog, and I was pretty annoyed that I couldn't just require a file and get on with it.

Laravel changed this for me after I finally decided to buy into doing stuff by command line (since I started abusing artisan). The level of convenience, the automatic management of dependencies, the ability to pull down packages as I needed them was great.

Number 4 was my concern for a long time. But you don't actually need to do anything with composer if you've done the dump-autoload; you can pass on the files and it will work fine! Composer's work is basically just downloading the needed files, setting up the loading process (for all the different loading mechanisms) and it just writes everything to PHP.

I think this discussion boils down to how people ask for binaries and others ask for makefiles.

In the end, though, you don't even really need to use Composer in Laravel! If you want to manage requires() on your own, and install things separately, you can do that too. Similarly, when projects on github offer Composer install instructions, you could also just pull the files straight off the repo and include them yourself! Of course, then you'd have to deal with how you autoload everything, which order to do so, etc, but that's why Composer (and other standards like PSR-0) were made.

Perhaps it just depends on the package too. I mean, I honestly don't think using composer/npm to add Twitter Boostrap CSS and JS is necessary, surely? Maybe in time, using artisan more, using composer more, it will make more sense.

It's definitely not necessary if you just want to pull a package down - and you don't have to, as a normal git pull (or copy-pasting files from github) would work just fine. It begins to make more sense as you deal with more and more packages, each of which need to get updates and dependencies of their own. Then you also get the bonus of not having to deal with autoloading on your own.

Hmm, updates.. haven't thought of that. Lets say I update a package on my test system, I assume by just updating its version in composer.json? and if that works, great, but if it breaks my app, could I roll back the version in composer? That update/downgrade of package versions would be a nice advantage I suppose.

A dependency manager is like version control, at first it seems complicated and unnecessary and then a few weeks later you look back and wonder how you ever did without it. A dependency manager allows you to delegate responsibility for managing your dependencies to a third party, in the same way you delegate responsibility for templating in your views to Blade and in the same way you delegate responsibility for modifying your database to migrations.

You're choosing to be the dependency manager for your projects, and if that's what works best for you that's okay, but for most people they would much rather assign that responsibility to a program which can perform the function far better than any human.

Jeffrey Way has a fantastic lesson on Composer (how to use it, what values it provides) on Laracasts, it's well worth a watch.

amityweb said:

Hmm, updates.. haven't thought of that. Lets say I update a package on my test system, I assume by just updating its version in composer.json? and if that works, great, but if it breaks my app, could I roll back the version in composer? That update/downgrade of package versions would be a nice advantage I suppose.

You can set a specific version or even commit, so you can just go back to a really specific version.

1. Updating composer does take some time, mostly because of having to check all the dependancies, version contraints etc for compatibility. But when you distribute your app to your production server, you just run composer install, which is a lot faster (don't know about memory, but I suspect also less memory) and just install exactly everything that is in your composer.lock (so add that to your repo!)

2. Yes that is a bad example, don't use Composer for js/css, just use Bower for that. The advantage is that you install a package and it checks the version, it checks if you need additional packages (a library used by that package) and autoloads everything. Simple packages can be installed, but with complex packages, you can have something like. First download X, then put Y in this version (be sure that you use version Z) and include the files here etc. Composer does that for you.

3. Yes you probably need them. But you can use composer install --no-dev, to skip all the 'development' packages, like phpunit. And don't worry about size. Disk space is cheap these days. But you could use a package like this: https://github.com/barryvdh/laravel-vendor-cleanup which deletes docs/tests etc.

4. You can just distribute it. Make your package available on github/packagist for Composer users, but you can also create an archive with all the vendor files included, so the end-users can just upload your package.

You don't HAVE to use it, but it really does make life a lot easier, especially for updating your packages.

On the note of performance, you can setup HHVM on the system (64 bit only support for the precompiled packages.) Then alias composer to be ran with hhvm, something like 'alias composer="hhvm /usr/local/bin/composer"' in your shell's rc file. It will greatly speed up the running of composer.

However for initial setups where you need to give it your github credentials, I find hhvm causes it to fail. So I manually run composer with the PHP cli for that, and from then on with any given system just use my aliased hhvm method.