I've added a third party library to my application using composer and it is a submodule. I want this submodule to be available to my parent git repository so that I can push it to my git repo. How can this be done? I want to preserver the current submodule so that I can continue to stay updated with that library.
You should add the vendor folder to your .gitignore file:
echo "vendor/" >> .gitignore
I do not completely understand why you want to use submodules, but my educated guess is that you don't need them for anything you want to do with your application and the library you are importing with Composer. Ignoring the vendor folder will make git to not mention any repositories checked out inside it as possible submodules.
Do commit your composer.lock file, and also avoid depending on branches of any library: Use tagged versions.
Related
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.)
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'm using Symfony2 and for my projects I normally do composer require name/repository which will install the repository in the vendor folder and add a line in the composer.json including the package and the installed version.
Supposing that I fork a project because I want to add something to it or fix a bug and use it in my Symfony app, I'd have to run composer require myname/repository, modify it, test it and then submit a pull request. Afterwards, after the pull has been commit to the original repository, I'll have to delete my own and remove it from composer.json and reinstall the original repository.
Is there a better workflow to this that doesn't have to change the json file that much?
If I want to create a module inside the vendor folder, what are the git commands to create a subtree (or somehting else)?
Scenario:
I update the module
Push it to github
My colleague wants the update too, should he pull from github, or just update composer?
Then he has to make his own changes and push them too github
I tried some solutions but I felt like they where not the best, how does everybody else do this?
Scenario:
I want to override some view files from an existing module and create my own module for this (yes it has to be a module), extending from the original module
Do I need extra steps for this? And a separate composer package?
How can my colleague install this module and make some changes?
If you want the module to be accessible to everybody the easiest way to do this is to create a composer package for it. Then you just add it to the composer.json file and you can both use the package just by doing a composer update.
Remember to tie the git repository to packagist (through webhooks, when you create the packagist package you will see instructions), so each time you update git, an update to packagist will be available.
To push an update the module just browse to that particular path and do a commit / push to git like any other package.
If you do not want to create a packagist package, then you can always create a repository like this in composer.json Use PHP composer to clone git repo.
I have a project here that's a large Symfony2 app, I'm looking to introduce git submodules to components we're building here in-house. The issue here is that each component also requires composer packages for itself to function properly and now I have composer packages for the symfony2 app and composer packages needed for the component and I'm unsure how to handle/setup these dependencies here.
At the moment I'm manually running 'composer install' for each component (git submodule) we add, implying that each component has its own 'vendor' folder, this is far from ideal so I'm coming to Stack to get come good advice on how to keep these 'symfony composer dependencies' and 'component composer dependencies' easily maintainable.
I don't need to make sure the version of the symfony2 app's deps are synchronised with the components deps, i just need to make it simple and maintainable without having to run 'composer update' with each git submodule we setup.
Thanks!
EDIT
I'm now using composer's repositories key to define URL's to my companies private github repos. I'm able to pull in a singular private repo, lets call it Repo A. However when I add Repo B and make Repo A require Repo B it doesn't resolve properly.
composer.json for Repo A (user-reporting-component): https://gist.github.com/dragoonis/6ea92e062762c516baea
Composer.json for Repo B (database-component): https://gist.github.com/dragoonis/e54b47b75a79b82ebaea
The following error message occurs: https://gist.github.com/dragoonis/d79cd2c2dd5cc50bcd2a
The package of opinurate/database-component does exist as it's one of the repos defined in the respositories key.
Conclusion
The end solution here was to use Satis to setup what is your own private version of 'packagist' what will work alongside packagist.
I setup Satis at 'http://packages.mydomain.com' and added a 'repositories' key in my main apps composer.json file to that URL. Now when evaluating package names it will use your own custom satis server to give you git URL's too.
I would say your best bet is to add those components via composer as opposed to git submodules. It makes coding and maintenance a bit more complex, but it ensures that your application is aware for all the actual dependencies.
If you don't want them to be public and want an easier way to handle them, then i would roll out a Satis deploy locally and register them all there, adding that satis repo to your composer.json.
Satis is a simpler version of Packagist, as long as the server with it, and the machines that run composer install have access to your private repositories, nothing else will see them. There is documentation on the Composer website at: https://getcomposer.org/doc/articles/handling-private-packages-with-satis.md
You will then setup packages.yourcompany.com and add it to your composer.json as an alternate source of packages. Everything stays private.
Reply to Edit:
This is happening because composer compartimentalizes, which means the "repository" is only known to your project's composer.json, the one in Repo A does not know, so it cannot find it. You must re-define the repository in that one. Even using Satis the "satis" address must be added to all composer.json files involved.
Add the "repository" stuff you added in your app to the composer.json in Repo A and B, it should work it all out.
I think this maybe sounds a bit similar to what you want to do, so I thought I'd post the link in case was helpful and you hadn't already seen it How do I use a Git submodule with a Composer loaded library?
You should use a .gitignore file containing something like that:
web/bundles/
app/cache/*
app/logs/*
app/sessions/*
build/
vendor
When developing you should launch php composer.phar update from time to time. When your work is validated, you should commit the composer.lock file with your development.
When deploying, you can then just launch php composer.phar install.