Level 75
Yes, if something goes wrong, you can always delete the vendor folder and do a
composer update
// or
composer install
Which re-creates the vendor folder.
Jan 11, 2019
8
Level 1
Should I really be gitignoring the vendor folder?
I know it's recommended, but in the past (before composer), working with Zend Framework and the like, EVERYTHING was included (except certain temp or CMS files and folders), including any vendor folder.
This honestly this made versioning easy, in the sense that if we moved servers or had to reinstall on a prod/qa/dev computer, we didn't have to hunt down the correct versions, and allowed seeing easily what was actually changed there even when (gasp) customizing code in those folders (which I'm against anyways).
So, moving forward, on a team that's new to Laravel and composer, is composer really good enough when installing/uninstalling/updating/downgrading on prod/qa/dev environments, or is there too much risk in losing code or changes or time by ignoring all of this source code in the vendor folder and simply relying on composer to "make everything right" if something has to be reinstalled/reverted/updated?
EDIT: Here's an example of our current .gitignore file, tailored to Laravel Mac PHPStorm basically:
Level 35
is composer really good enough when ..
Yes, composer is the industry standard. The only thing is that your development team needs to understand how it works. Your composer.lock is the actual file that states which version of a package should be installed. So if that file is part of your git repository and you run a composer install on your (local) servers all the servers have the exact same version of the packages.
Never ever run composer update on your live servers. Always do updates on your local machines and commit the new composer.json and composer.lock file and start a new deployment.
https://www.engineyard.com/blog/composer-its-all-about-the-lock-file
Level 1
Clarification: When trying out different 3rd-party repos, I want to try to not have a weird junked-up mess that's hard to manage, or have bugs/behavior only happen on certain boxes and not others because vendors is different across computers even though the repo files are the same.
Level 1
@CLICK - I don't understand what you mean by only start a new deployment... I can't continually start a new deployment on a live server after we've updated on our local computers.
I'll read the link, but if we run composer update on our local boxes (whenever?), commit the new composer.json / .lock files, why would we never run composer update on a prod server?
I'm just curious what you do in your situation. Right now we have multiple developers, a QA test box, and a Production box.
Level 122
because if you test and then a new package update is released, when you run composer update on your production server it will grab the latest version. Your production machine is now ahead of your local environments.
Composer.lock contains references to the exact versions used in your last update so composer install will be using the same version of all dependencies.
Its also critical if ypu are running a server farm. You dont want package revisions between deploying nodes
At Laracon EU, Alex Bilbie recommended commiting vendor to git so that you can rebuild yoursite if Github is down.
Level 1
@SNAPEY - "... recommended committing vendor to git ..."
This is why I ask... most other projects I've worked on (with frameworks) just committed everything and did not put vendor(s) on ignore.
I understand their reasons but with a new project in Laravel, I'm not sure composer/git/Laravel is robust enough to not have to worry about vendor being on ignore.
The vendor folder is 57 megabytes whereas the rest of the laravel folder is less than 10... so that's a significant difference, but it might nice to see what actually changed in various composer updates or just have a hard version that can be installed from elsewhere.
Would it be worth making vendors a sub-module in git that we could make commits and push with after a composer install/update? Could that be automated? Or is that more work than it's worth?
Level 75
@davestead you are totally confused about the vendor folder in laravel. That vendor foder is always available from the laravel github site, and the version in composer determines which version gets pulled in.
So why are you picking at something so simple.
That is true for any supported version, now it may not be the case for an old version 3.
So yes always have a zipped backup of an older version.
This stuff is really common sense.
Level 1
@JLRDW - I know how the vendor folder works... if GitHub is down or not working for some reason, then nothing in the vendor folder from GitHub can be installed can they? I am going off Snapey's comments above in regards to that.
I know how composer works too... I'm not confused about how vendor or composer or GitHub works here. I'm not picking at anything.
The question is whether there may be a reason to not have vendor on gitignore... I gave some possible reasons, so did Snapey and Alex Bilbie... I recommend you read those again.
I know how to do backups; not everything you're saying here is common sense as has been explained previously. I'm afraid you may have misunderstood so I simply recommend reading the previous comments or considering them more carefully. I've gotten enough info from this thread anyways, thank you and goodbye.
Please or to participate in this conversation.