We have composite project with many custom and 3rd party libraries.
We are looking for a way to update most of the sub project with composer update..
but to be safe, we need to lock down all the sub dependencies to the currently installed version.
I had no problems with tagged versions, but "dev-master" gives me trouble
can a Lock a dependencies "some/fu" : "dev-master"
(with current version 0.1) to stay as it is, and never update to 0.2 ?
The problem is that dev-master is a moving target. So the meaning of dev-master can change at any time.
Let's say that it represents the latest 1.0 development version. At some point the author of said library starts working on the 1.1 release, so they branch off a 1.0 branch, and dev-master becomes automatically the latest 1.1 dev version.
Technically the dev-master has no version it is a version and it represents the most current development state of the master branch.
If you have control over the source repository which you want to require you could make use of a branch alias.
Or you can update only specific packages like composer update vendor/package1 vendor/package2 or to shorten it specific vendors composer update vendor/* instead of a full composer update. As far as I know there is no possibility to exclude specific packages from update yet.
In addition to #Peh answer:
Yes, using dev-master is a bad practice. But if it is a really necessary you can pick up certain commit "symfony/finder": "dev-master#2633721877cae79ad461f3ca06f3f77fb4fce02e"
What scenario does lead to problems with master branch? when do you want execute composer update?
Related
I have the problem that during a Shopware 6 update (e.g. 6.4.18.0 -> 6.4.19.0) the root composer.json changes.
Since it is possible to install plugins via composer require all the required plugins and installed plugins are missing after the update.
How do i handle that? What is the best-practice for this case?
How did you install shopware in the first place? When you install shopware over the webinstaller, then you should update over that way as well and changes in the composer.json will be overwritten by an update so you have to add those changes manually again.
If you set up your project using composer you should update by pulling the latest changes and if you have manual changes in the composer.json, those changes will be merged via git.
With the new symfony flex setup all of this should not be necessary anymore and your root composer.json should not be touched anymore during updates. The flex setup will be the default setup starting with 6.5 and also the webupdater will switch the existing installations to this setup.
You can follow this guide on how to switch to the new setup.
I am using Neos CMS for my website. Now I am trying to update the CMS via composer update. Inside my project I installed a package that is now abandoned. That resulted in a failed update because the composer.json inside the package does not require the newer version of the CMS. Basically I just need a way to completely ignore that package while composer is updating. --no-dev did not work. That resulted in: Running update with --no-dev does not mean require-dev is ignored, it just means the packages will not be installed. If dev requirements are blocking the update you have to resolve those problems. Would be great if someone has an idea.
If the source of the abandoned package is still available, you may create a fork of it, change the requirement settings and then include your fork like described in How to require a fork with composer?
A much better way would be to exchange the package with something else which is still maintained. If you rely on the functionality of this package in your project(s), it may be worth to maintain an updated fork of it on your own.
I'm installing Drupal 8.x via composer downloading any dependencies from the Internet and all works fine.
In this way however there is no guarantee that the same versions of dependencies will be available every time I install. One server might have an updated version of a module than another Drupal server if I install in different time. I would like to prevent against this by using a local mirror.
Is it possible to provide a local mirror to composer and how?
Any example / reference / suggestions?
If you are worried about the versions, then the best way would be to define the exact versions you want in your composer.json if need. But apart from that, after you install your dependencies, you have a composer.lock file that has the exact versions in it. This file is committed to your version control and used as the base to install: this way you always get the same versions (until you update of course).
A separate problem might be that there is no internet, or the specific versions are not available for some reason. This shouldn't happen (often), but in that case you should pick this up before you 'release'.
The best practice would be to build (finding out if you have all packages available) and then release. You could even create a separate build server that creates your project including the vendor dir, and push from there. The fact that your vendor dir is not in your version control does not mean you have to get all dependencies on your production server each time
This means you have a local copy of your vendor, which is not a local mirror of composer per se, but close enough for comfort.
I have a Laravel 5.3 project which I am upgrading to Laravel 5.4 and due to some changes in Laravel there are some dependencies that need updating. Every dependency except one had an updated I could safely switch to.
Checking github I found others with the same issue and an easy solution on how to fix the problem. However, due to unknown reasons the developer of the dependency has stated that they will no longer support it and would consider it deprecated. There are pull requests to fix the issue but no one can accept these requests.
What I can do is navigate to my vendor folder and make the changes myself but I know this isn't the right way to do things as the changes will get overwritten eventually and we are back to square one.
How do I deal with the problem of outdated/unmaintained dependencies with problems I could fix on my own or solve with the help of others who share their solutions?
1) I could copy the files from vendor and try to just integrate the third party files into my project.
2) I could fork the repository and make the required changes and either add my forked version to packagist (doesn't feel right) or add my forked git as a repository in the composer.json file.
I am open to other ideas, thanks!
I will add the way I have solved it for now. If someone has a better answer I would gladly accept it.
In my case the repository in question is a Github repository which I could fork. I can then clone the repository and make any needed changes. Let's say that the following is what I have in my composer.json file.
"require": {
"someoneelse/project": "^1.0"
}
Inside my composer.json file I found the "someoneelse/project" for the dependency and changed the current version requirement "^1.0" to "dev-master". This will pull the latest commit from the master branch and put minimum-stability as dev.
I then added my repository to composer.json. You can do this like so
"repositories": [
{
"type": "git",
"url": "https://github.com/markustenghamn/project.git"
}
],
"require": {
"someoneelse/project": "dev-master"
}
Running composer update will now fetch the latest version from my forked repository. If someone decides to start working on this project again I can always change it back. The dependency may require other dependencies in forked projects composer.json file, remember to update these if needed.
We're using composer, satis and SVN to manage our in-house PHP libraries.
We commit changes to SVN trunk during development, then tag versions (following semantic versioning) when they're ready for testing.
Once a library version is tagged, we can use composer as part of our deployment to the testing environment. Following successful testing, we'd then deploy that same version to production.
The issue here, is that once we've tagged a version for testing, we have to be very careful as the newly tagged version will be picked up by composer when preparing the next prod release.
What I'm imagining, is that we'd tag a version as a beta or RC, (eg v1.1RC1) and somehow configure our deployment process such that it will refuse to deploy an RC or beta to production. If a version is tested successfully, we'd re-tag that version as a released version (v1.1RC1 -> v1.1) and release that.
Can this be achieved?
From what you are saying, I understand that you are actually afraid of tagging a new version of a library because that code could actually be used and break that other application, right?
One approach would be to do good testing. I don't see it should be a problem to tag a version of a library. If the tests are all green, there should be no reason not to tag it. This would work even if the tests are basically only "let's see if it works, manually".
Now the second step is to integrate that new version into the application: Run composer update and see if the application is still running, i.e. start all the tests and wait for green.
I guess it might be a good idea to have a separate area where you check out the application, intentionally run composer update to fetch all the newest libraries, run all the tests and report that a) there are updates and b) they work. A developer should then confirm the update, i.e. do it again manually and commit the resulting composer.lock file, or grab the resulting lock file from that update test.
I don't think there is benefit in using non-production release versions. You have to deal with the next version anyways - constantly toggling the minimum stability setting or adding #RC or #beta flags to the version requirements of the library don't really help.