I made a new branch, because I need to update a certain dependency and adjust the code so the new version works.
After I pushed the branch. I switched to master and noticed that the package is also updated. I had to revert the update.
I noticed that this happened because the /vendor/ file is included in the .gitignore. After some reading I understand why. In case, I want to pull the project somewhere else, I should use composer install to install the dependencies.
But I am thinking, is it really worth it? I just could upload the whole vendor folder and when I pull it somewhere it would just work. The only downside it, that the vendor folder may be huge, am I correct?
I do not see an other option how I would be able to update and test a dependency on a different branch.
Is it save to remove the vendor folder from the .gitignore?
Is size the only reason why it is there?
If I keep the vendor folder in .gitignore, which seems to be suggested everywhere, how do I update a dependency on a branch only without destroying master?
I could recreate the whole vendor folder every time, but thats insane, that sounds really wrong.
It is recommended to have vendor folder not in repo.
composer.json file should pushed to git repo. You just to run composer install each time when you change anything in composer.json it will sync vendor folder with composer.json, on first time composer install will create composer.lock file to lock the versions of packages,
To see more
I'm OK with running composer install every time that I swap the branches.
But I have an idea for your case you could keep vendor in your main .gitignore file then go to the vendor folder and initialize a git repo in that folder from now on you are able to switch between branches in that sub git repository.
Note: be aware that you should also change branches in the main repo when you want to test your dependencies. (It's better to keep the name of the main repository's branch and the sub repository's branch the same.)
Related
I am sorry if this has been asked before but after searching for a while I couldn't really find answers to my dilemma.
I am part of team that is working on a PHP project and we use github for our version control. We would like to implement a PSR-4 autoloader and every single guide uses Composer so we would as well. Now, while searching I learned that the vendor folder should not be included into github, but only the composer.json and that every developer needs to install composer onto their own computer.
Does that require the autoloader to be created again on every developers computer.
And finally, when the project is done, we would like to upload it onto our website, but the only way we can do that is through FTP.
Which files should be uploaded to the live website and what would happen to th autoloader?
You need to commit the composer.lock file as well. That's super-important - it means that whenever someone else checks out the code they get the same set of dependencies (including their exact versions) installed to their /vendor directory.
That's why you don't need the /vendor directory to be committed - the lock file takes care of ensuring the dependencies are fixed.
The composer.json defines numerous potential versions of your dependencies that meet your requirements. Running composer update essentially checks to see if a more recent version is available that meets those requirements. That's the difference between install and update - install goes off the lock file and knows exactly what to look for - update goes off the json file and could return different results at different points in time.
In your composer.json you can define the autoloader by telling it where your root namespace lives.
"autoload": {
"psr-4": {
"RootNamespace\\": "library/src"
}
},
When your colleagues have run composer install it will create the autoloader for them in a consistent path.
You have options for deployment:
You can either upload the composer.lock file and run a composer install on production, or do it ahead of time and upload your vendor directory as part of the build.
I do the latter as I would prefer if there was an issue at this point to know about it before any files are changed on the production server. The alternative could leave a botched upgrade on production with missing dependencies. Safer to install those dependencies first and transfer everything in one go.
As an aside, I also like to install a fresh release to a separate folder on production named after the git commit and then symlink it as part of the deployment step. This ensures you don't have a half-updated application whilst you wait for the rest of the files to be uploaded. This approach would also eliminate the issue mentioned before, meaning you could do your composer install from production.
If I don't have ssh access and can't run composer command over server.
How can I upload laravel packages properly through GIT repository, so that my project will run without any problem .
I know If I remove vendor folder from root .gitignore then vendor file will up to the server.
But still I have doubt, I have to do other thinks also.
I am not good in git thats why before messing laravel I am asking this.
The general recommendation is not to commit the vendor directory, that's why Laravel ships with a .gitignore file that contains the vendor directory amongst other things.
However, there are situations such as yours where this is not possible, so in that case there is a nice section of the Composer Documentation that offers some advice on how you should handle committing the dependencies to version control:
Should I commit the dependencies in my vendor directory?
I have a git project with one branch, I´m trying to clone all files in my local folder, but I can´t get the vendor folder. I would like to know if I can do it in other way to get also vendor class.
I´m running this:
git clone -b branch_name repo_URL
As I say, I don´t get one folder. What I need to do it to get all files?
PD: I can´t download a ZIP of the project.
You are not supposed to find that vendor folder in your repository. It would be useless redundancy.
In modern PHP projects, Composer is being used to manage external dependencies. When running composer update, it reads a file composer.json (which should be present in your repository) to find the most recent versions of the external packages to be used.
This creates a file composer.lock (which should also be in your repository) with the exact versions and commits that got downloaded. If at any later time someone (like you now) wants to recreate the contents of the vendor folder, they run composer install, which will try to get everything that was once downloaded.
So the first step for you is to download Composer, then run composer install (depending on your way of downloading, it might also be php composer.phar install or something close to that).
Reasons for composer install to fail is that dependencies can no longer be downloaded because they were removed from the internet, or that the project is too old and has too old versions of said files so that it does not run with current versions of Composer (although this should be very rare). In any case: If you encounter errors, ask a new question here with all the details, including the full output of the Composer command.
The reason why you don't get the vendor folder is because the vendor folder never went up to the git repository. If you see the .gitignore file, you will notice a :
/vendor
This tells git to ignore that folder and not to send it up to the git repository when you are pushing. There is no way for you to get that folder unless you find the original project before you pushed to the git.
I've done lot of Google but still looking for solution, I'm working on Laravel5 project & wants to set it up with GitHub so multiple developer can work on it.
I've install Laravel & place in a repository on Git, Now I cloned it on my local machine & another developer also clone that repository in his machine and start working.
But issue is that, I have installed a package for HTML forms in my machine by composer & push my code to github. But when another developer pull the repository then his code is break because composer.js is updated for that package but actually that HTML package is not exists on his machine.
Can anyone help me to short out this, or is there any way so we ignore vendor folder, composer.js, app.php etc files during git Push?
To answer your question specifically, yes you could choose to ignore the vendor folder, composer.json and app.php files when you push to git. To do this, you would simply need to update your .gitignore file to reflect this. I.e, include these in your .gitignore:
/vendor
composer.json
/config/app.php
But then the next question is whether you really want to do this, as doing so would mean that changes you make - and any subsequent pushes - may not be compatible with work the other developer is doing down the track.
If you exclude the /vendor file and the /config/app.php file but leave the composer.json file in there now that the other developer already has a copy of the core files, the updated composer.json file they download would allow them to use composer install to update the project with the new package.
However all of this would be problematic for a developer who joins you down the track and doesn't have any of the current files.
I'm new to Composer (getcomposer.org) and wasn't sure how it works if I install a package locally using Composer and then push my codebase to my production server using Git. Do I have to run Composer again on the production server?
cheers,
J
When you setup your project, you add your dependencies into your composer.json file in your local project directory.
Once you have done this, you will need to run composer update. You can also run composer install, however, without a composer.lock file, composer install actually runs composer update.
Composer update goes out and resolves all the dependencies of all the libraries you are using, downloads them to the /vendor directory, creates an autoloader script and generates the composer.lock file.
For your project what you want to do is version your composer.json AND your composer.lock file.
On your production server, you will always run composer install, which insures that the libraries on your production server are the exact same ones you utilized in your development process.
composer install is also a lot faster as it does not have to do all the dependency management work, and can almost always just pull a specific commit#. It doesn't have to look at version strings. Thus is is usually very fast, once a server has already gone through it once.
In development the only time you should run composer update, is when you introduce a new library OR you have an issue where an underlying library has been changed and you know that you need to have composer go out and re-calculate the dependencies. composer update always recalculates and downloads the latest revisions of any library available even if the version level did not change. This means that there is a potential for something to have become broken, necessitating the potential for as full a set of regression tests as you might have available. In short, something having nothing to do with what you're actually changing could have broken, so you only want to introduce the potential for change when you are forced to.
Of course, if you did introduce a new library, you have no choice but to run composer update.
Once you run composer update, your composer.lock file will be updated (as expected) and the production server will pick this up when you run composer install on it.
As others stated, put the vendors in your gitignore. The point is that these are external libraries that you depend on, but that do not belong in your project, and should not be versioned. In the old days some people utilized git submodules, and it's a big PITA you really want to avoid, not to mention that submodules don't address dependencies of the libraries you included.
It depends how are you working. If you, like getcomposer.org says, are ignoring the "vendor" folder then you need to run it again. If you are versioning the "vendor" folder then you don't need to run it again.
Have in mind that composer will get in charge of managing your dependencies versions, so there is no need to put your dependencies files under versioning. If you put these files under git you will only make your repository bigger.
Read https://getcomposer.org/doc/01-basic-usage.md#installing-dependencies.
For clarification when you ignore the "vendor" folder Git don't track the files under the folder so if you clone the repo it will be like composer never was executed