I regularly observe the following behaviour:
When I try to execute composer update mynamespace/myproject, it fails because if conflicts with a dependent project "mynamespace/mydependency", which is 'locked' at a specific version - the version specified in the composer.lock file. I don't get what 'locked' means in that context, but I observe that the update works well once I deleted the entry
{
name : "mynamespace/mydependency"
...
}
from composer.lock. This behaviour is in contrast to what I understood so far that the composer.lock file was supposed to do - recording what exact versions are installed without specifiying any restrictions on composer.json.
Since my assumption has been proven wrong, I would be thankful to some clarification.
Never ever edit the lock file by hand, that will only cause trouble. If updating a single dependency does not work, you've found the reason already: cause it's still needed in the current version by any other dependency.
To see why an update is not possible, you can use composer why-not, followed by the package name and the version you want to update to. For example, the following command could list why exactly updating to v3 is not possible:
composer why-not mynamespace/myproject 3.0
Now, you can either decide to skip the update for now, or add any of the packages that are listed there to your update command such that these also receive an update.
NB: it's very common that updating a single component (and nothing else) is not possible, especially if this is not a minor update
Related
Is there some change log to check what is updated the last days?
We used composer to update modules, but we are looking for a way to see what exactly was changed the last days.
Can we check this somewhere?
Composer does not store a record of what installs at every time. It simply updates composer.lock with the discrete package versions that were installed.
Since usually composer.lock is stored under a version control system such as git, it tends to be enough. If you want to have an easier way to check what specific versions are installed on different updates, you could always store the result of update on file to see what was upgraded to what:
composer update --no-ansi &> update.log
Or maybe more practical, run composer info > installed.txt and commit that file after each update or require. That way you would have an easy to read and easy to diff file to see what versions were installed along the project lifetime.
I followed instructions from an answer of a similar topic(https://stackoverflow.com/a/17531897/4388482). Well, my app is getting deployed on Heroku but it doesn't work good. I'm getting the following warning
Your project only contains an 'index.php', no 'composer.json'.
Using 'index.php' to declare app type as PHP is deprecated and may lead to unexpected behavior.
Do I need to install something maybe?
UPDATE
Project structure was initially this:
I did the following:
Installed PHP 5 and composer.
I renamed package.json to composer.json and removed package-lock.json.
Typed "composer update" command. I got "nothing to install or update" message.
Added vendor to gitignore. Pushed changes to heroku.
I got the following warnings
Your 'composer.lock' is out of date!
Composer vendor dir found in project!
The complaint that Heroku has is regarding this folder.
For the record, the contents of this folder presently are:
bootstrap
fontawesome-free
jquery-easing
jquery
What has happened here is that someone has committed dependencies to your version control, which is not good practice. It will work as is, but it is not very easy to do upgrades, especially since you cannot easily see what versions you currently do have.
There are three ways to go about this.
Decide if these are PHP dependencies, by searching Packagist. There is a Composer dependency for Bootstrap, but you would need to see if the version you are using is available (or whether you can upgrade to one that is available).
Decide if these are JavaScript dependencies, by searching NPM. I wonder if it is worth examining the contents of your package.json in case these are already covered. For what it is worth, I would generally consider these candidates for JavaScript libraries rather than PHP, but do what works for you.
Choose to leave these dependencies committed in the existing vendor folder. It will work, but it is not ideal for the reasons already stated.
In the last two cases, you could probably get away with a composer.json file thus, which you should commit to the repo:
{
"require": {
}
}
You could try a composer install after this, to see if it will generate a .lock file on an empty dependency list. If this does generate, then you should commit this also.
Is there an automated way of updating the version number in composer.json and adding the necessary tags before publishing, like the way npm version does?
I mean, if you had a composer.json with the line "version": "2.1.3", and executed:
composer version minor
It would do the following:
Updating the version number in composer.json to 2.2.0
Triggering composer update to update composer.lock
Making a new git commit
Making a new git tag v2.2.0
I know that the composer version command doesn't exist, but is there an equivalent tool?
npm version does stuff that you very likely do not need for Composer:
The version number is not recorded in composer.json if there are other means available - and because you are referring to Git later on, they are available.
Updating dependencies in the lock file is unnecessary. The lock file will be ignored when the project you are dealing with is included somewhere else.
Because nothing has changed in the project, a git commit wouldn't do anything.
All this leaves you with creating a new tag in the Git repository. Putting this into Composer would mean you'd exchange one command with another, without any big benefit besides you won't have to lookup the current version number you are dealing with if you use some of the relative version parameters.
All in all I'd say that simply tagging your new version is enough for Composer. You'd probably need to have some infrastructure in place and configured to make the world aware of the new version:
If your package is open source and on packagist.org, you should have a post-commit hook to notify them as soon as a new version is available. This is a standard option on Github, I don't know about other source code hosts.
Otherwise if you have to feed closed source code, you'd probably start a new update cycle of whatever system is used to create an alternative package information source (be it Satis, locally hosted Packagist, Toran Proxy or Private Packagist)
This however depends on how you set up things.
If for some reason and despite all voices against it you still want to use a tool like the OP asked for, https://www.npmjs.com/package/composer-version works quite well.
I am working on a Laravel application, and I ran the command composer update in order to install new packages I had added.
I had changed/added some files in the vendor directory before that, and those files that were added have been removed. I have not committed to my vendor directory (another mistake!), hence I can't get them back through git.
Now my questions are:
What happens when composer update is ran?
Why the files removed are not in the Recycle Bin, what has
happened to them? Permanently deleted?
As well, I am well aware that I can roll back my composer update, but that will not give me back my modified files, it would rather install the original files of the previous version.
Please do let me know if there is any other way (even file recovery) would help me to get these changes back.
composer update looks for new versions of installed dependencies and, if found, installs new versions instead of the old ones. It doesn't care whether any changes were made to installed dependencies, because it's looking just at their descriptions stored in the composer.lock file.
The files most likely cannot be recovered with composer for reasons mentioned above. You can try looking for lost files inside the cache directory .composer/cache, but I see no reason whatsoever for the lost files to be there. Yes, they are probably permanently deleted and, if those are critical, you should look for a file recovery program.
You definitely shouldn't store any modifications made to dependencies for the mentioned reasons.
Also, you probably shouldn't add vendor/ to your repository, for all dependencies are tracked with composer.lock anyway, and changing dependencies inside vendor (making them hardcoded) is against composer workflow.
EDIT:
As suggested by Kévin Dunglas, you can also try to look for the lost changes in the local history of your IDE (e.g. in PHPStorm).
I've made custom changes to a package (Its wrong, I know) and I want to preseve these changes every time I update composer .. How can I?
Tag that version in your own repository and depend on the tag without any wildcards. Composer will never try to grab a different commit then.
If you are unsure which version to use, and the upstream project didn't release a tagged version yet, start with 0.0.0. If you are basing your work on top of a tagged release X.Y.Z, you might tag your changes as X.Y.Z.1 and depend on that exact version.