I noticed that many (large) PHP applications use Composer for managing the dependencies. I'm currently trying to figure out if I should switch to Composer (at the moment I'm simply keeping my dependencies in a folder called vendor/ - without being able to automatically update them).
I prefer this way because:
I don't rely on 3rd party websites/repositories to get the source code (I find this as being a security concern as well); and, also, what happens if one of the repositories goes down for any reason? I will no longer be able to update/install my application?
I don't need Composer installed (on the local machine/production machine); this is just a minor issue;
It's faster; obviously, the updates can be pushed faster to production if they come from a single source - it's enough to just update my bundle (that contains all vendor packages) and then simply push/pull the changes to/from production;
I'm using many components that are not aware of Composer (standalone libraries, GitHub repositories that are lacking the composer.json file, many JS/CSS assets, even isolated single PHP classes that I prefer to think as 3rd party libraries etc); if I were to use Composer I would have to use a tool like Satis to manage these (and things get more complicated without a real benefit);
I have my application deployed to several domains (around 25) and it's easier to maintain it this way (a single bundle where all changes get [automatically] pushed and later on the bundle itself can be pushed to production);
There are many changes and updates (a few commits each day to the main application package) and I find it easier to simply push these commits to production rather than setting up tags for each commit so that Composer can see the difference and update to the new version;
On the other hand, there are some problems with my approach:
First of all, I'm including all the vendor packages in my codebase/build; I know this is not a good practice and I understand the arguments behind this (I'd prefer to avoid this);
It may be a good thing that I'm able to trace all source code changes to my application in a single repository (I use git). Obviously, all vendor changes will be reflected in the bundle repository. But on the other hand there's some redundancy - I'm also working myself on some of the dependent vendor packages so it doesn't make much sense to COMMIT the changes there and add the relevant message to the COMMIT and then the same changes to be commited on the bundle package, as well;
More bundles: I have a few applications that are extensions of the main application - they provide their own business logic, additional controllers etc; For these I need to create separate bundles that will again contain all the vendor packages - so, whenever a vendor package gets updates I need to propagate these changes to the additional bundles, too;
It's not that straightforward to work in a team: how should the process go? Each member should update the core application package then update the bundle itself? Then the other members will download both the bundle and the core application? Again, I find it somehow redundant;
My approach worked so far, but I think that I might be missing something in this whole developing/deployment process. I'm trying to stay focused on developing rather than managing dependencies/deploying so I'd prefer that the deployment process is as smooth and transparent as possible. Also, with this approach the update on each server takes about 30 seconds, with composer it would take a lot more (as the update in Composer needs to connect to all 3rd party repositories).
So, as a summary:
I think there's a redundancy in my current way of working;
I'd like to know if there are better ways to handle this (simple deployment process to all my 25 domains - about 20 of them are sharing the same codebase; no source code redundancy; team work friendly);
There are many updates to the source code each day so the update/deployment process should not be a hassle;
I really like the modular approach for developing: having an application that *requires* other modules; if I need the same application just slightly modified I add an additional module that changes some of the existing logic and that's it. I'd like to keep it this way without having to build bundles made up of modules and then install the bundle.
Any ideas for improvement?
Edit: I found two articles related to this topic that are quite interesting: http://www.redotheweb.com/2013/09/12/should-you-commit-dependencies.html and http://addyosmani.com/blog/checking-in-front-end-dependencies/. I believe that what they are mainly saying is that "it depends". So, I assume that, at least for me it would be better to checkin my dependencies.