How to get Laravel, Composer and SVN to work together

Question

I am becoming very frustrated with how Laravel 4 and Composer work with SVN. Perhaps there is something I'm overlooking.

My workflow consists of developing locally then uploading to a DEV server, we use beanstalk ( http://beanstalkapp.com/ ) as our online version control and deployment system. When updates are ready to test we deploy to a staging server and then finally to our servers in our cluster with one click deployment.

However just about every article I read says to ignore the vendor directory and a few other files. I cant do that, those files need to be committed in order to be deployed to production! The problem comes when I install or update the current vendor packages composer deletes the whole directory while it installs the package/dependencies in which it deletes the .svn data and messes up my environment.

It appears the only way is to trash the vendor directory before updating composer and then adding the vendor directory again. I don't like having to do this, I was hoping I could see what files were being updated during an update.

So my questions are:

1 ) What am I doing wrong with my setup?

2 ) What can I do to have SVN and Composer/Laravel playing well together

Answer 1

I've been in a similar situation.

Our deployment made it necessary to commit the vendor directory. Which is fine, actually, because the result shouldn't be different compared with a fresh composer install guided by a lock file.

Initially I wrote a script that takes care of composer updates:

• Delete /vendor
• Run composer update
• Then recursively walk through all subdirectories and delete any remains of the source repositories (which boils down to deleting some .git directories because my dependencies all come from GIT - but it would be the same deleting all .svn directories recursively).
• After that add the vendor directory to the SVN repo
• Commit everything

If the script works fine (I used phing for it, which is especially nice for recursive deletion), you simply call it, wait some time, and are done.

But this won't make you happy, and some day you make the step to actually adjust the way deployments work. I think there are two possible ways: Either create a deployable artifact (check out the source, install dependencies, put it all together into a TGZ or ZIP, move to target server, unzip), or employ a hook during the deployment that installs the dependencies when deploying. Beanstalk seems to support hooks during deployment, so you should investigate that.