New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refresh lock file instead of updating? #754

Closed
EvanK opened this Issue May 31, 2012 · 17 comments

Comments

Projects
None yet
@EvanK

EvanK commented May 31, 2012

My peers & I are constantly getting the following warnings from Composer:

BC warning: your lock file appears to be of an older format than this composer version, it is recommended to run composer update
Installing dependencies from lock file
Your lock file is out of sync with your composer.json, run "composer.phar update" to update dependencies

Our issue is, composer update will not just rewrite the lock file format, it will update all versions of our dependencies. This is a problem for us because, for reasons I'd rather not go into (long story), we must keep using specific versions of certain dependencies...which is why we're using a lock file to begin with.

It would be useful to have a way to update just the lock file to a newer format, while maintaining the same dependency versions. Perhaps a composer refresh command or something similar?

@Seldaek

This comment has been minimized.

Member

Seldaek commented May 31, 2012

You have two options:

  • composer update nothing that will just rewrite the lock and autoloaders, but otherwise will keep everything that's installed as is.
  • Define your dependencies so that you can run update without having things blow up. This is the recommended way :) You can do stuff like requiring: "package/foo": "dev-master#a342f49" which will make sure it sticks to that commit hash, even when you call update.

We will however not add a command to just regenerate the lock file because that kind of makes no sense and goes against the concept of defining proper dependencies.

I hope this helps.

@Seldaek Seldaek closed this May 31, 2012

@EvanK

This comment has been minimized.

EvanK commented May 31, 2012

That is exactly what we needed, thank you!

@ericclemmons

This comment has been minimized.

ericclemmons commented May 31, 2012

@Seldaek Option 2 is exactly what we were looking for – being able to explicitly define the committish alongside it's originating branch. Thanks!

@Seldaek

This comment has been minimized.

Member

Seldaek commented May 31, 2012

Yeah it's not been available for very long (couple weeks), can't blame you for having missed it :)

@blisscs

This comment has been minimized.

blisscs commented Apr 1, 2013

I have the same issue.
I ran this command-
php composer.phar update nothing
then I get
Package "nothing" listed for update is not installed. Ignoring.
And then get same exception as mentioned above back again.
Could you help again on this.

@njt1982

This comment has been minimized.

njt1982 commented Jan 7, 2016

There is also now this:

      --lock                     Only updates the lock file hash to suppress warning about the lock file being out of date.

(for those who end up here from Google)

@chrisyue

This comment has been minimized.

chrisyue commented Mar 13, 2016

I tried --lock option, but still have got vendor libs updated

@HaykoKoryun

This comment has been minimized.

HaykoKoryun commented May 24, 2016

same as @chrisyue here, nothing or --lock ends up trying to resolve dependencies instead of just updating the hash.

Running version: 98b0af1386f7ff730c3330e2525c1d66998c7f90

@lifehome

This comment has been minimized.

lifehome commented Jun 5, 2016

Can someone reopen this issue? I'm running into the same situation... D:

@meglio

This comment has been minimized.

meglio commented Jul 1, 2016

I would also like a solution to updating lock file only without resolving dependencies.

@stof

This comment has been minimized.

Contributor

stof commented Jul 1, 2016

Checking that the locked dependencies are compatible with the updated composer.json is important. Updating only the hash without checking what is in the lock file would be bad, as Composer would think that the lock file is uptodate while it is actually in a broken state.

A composer update --lock will make changes in your vendor dir only if what is installed currently does not match what is requested by the lock file (i.e. your local install is not uptodate)

@HaykoKoryun

This comment has been minimized.

HaykoKoryun commented Nov 23, 2016

@stof I get that, however in one of our projects we have 65 dependencies, a mixture of composer and bower packages, some of which are external libraries like yii2 and others which are internal.

As some of the internal libraries change frequently we have to update composer.json and composer.lock every time we need the latest version. Since the changes are known, for example the only diff is in the code in the library itself and not in any of its own dependencies, all that is required is to change the version number and reference hash in composer.lock and run composer install. This works really fast compared to updating, as the latter would require composer to look at all the dependencies of the 65 dependencies unnecessarily. A manual override is what is needed here. For example, the install takes a few seconds, whereas the update takes longer than making coffee and getting a snack from the vending machine and we don't need those kind of excuses 😛

@sbuzonas

This comment has been minimized.

Contributor

sbuzonas commented Nov 23, 2016

@HaykoKoryun you can use the --root-reqs flag to only consider the packages in the root composer.json. I generally recommend that you use whitelists whenever possible... composer update my/package or composer update 'mycompany/*', this also allows for the dependencies of the whitelist to be considered when needed using the --with-dependencies flag.

@alakhdeveloper

This comment has been minimized.

alakhdeveloper commented Sep 29, 2017

Hello,

with composer the php and phtml file have to put in local directory to auto-overwrite. that fine, but how to unlock or add symlinks for js file? Please help.

Js didnt have any local directory to overwrite, so where i have to put js file which is locked by composer?

@dustyghost

This comment has been minimized.

dustyghost commented Nov 24, 2017

A workflow I was hoping for:
Branch A = working branch happy days, composer.json and .lock are working and in sync.
Branch B = very old branch, but has packages needed to make it work, not in branch A.
The goal, bring branch B up to date with the latest branch A changes.

I update to a branch A. I composer install. This get's all the packages I need from branch A in the vendor folder.

I then update to branch B, attempted to merge A into B, get a merge conflict on .json and .lock.
Manually fix merge conflict on .json, make sure that the composer.json is up to date with the versions from branch A, and include the new packages from branch B.

What I was then hoping for was a way to run either install or update, that could rebuild the .lock and would keep the versions of the packages in the vendor folder already (remember this was installed from branch a), and then update or install the new packages from branch B.

Basically rebuilding the .lock file based on what is in the vendor folder already, and then adding any missing packages, the missing packages can happily be the latest, but the ones in A really need to stay the same version when attempting to merge to B
It would be cumbersome for us to manually add the hash to the json with the amount of packages we have,

@curry684

This comment has been minimized.

Contributor

curry684 commented Nov 24, 2017

First of all you should never use commit pinning. You're kicking a 5 year old issue here, from the first early days of Composer, and commit pinning is currently explicitly considered bad practice, and even explicitly not supported by the Composer team.

Secondly I'd venture to say your expectations are flawed. You're more or less expecting to upgrade Windows 7 to act like Windows 10 by copying half the system32 folder from a Windows 10 machine. It will BSOD faster than a speeding bullet if you even get it to boot.

Project dependencies are an atomic part of the code base, and therefore branch, they reside in, and should never be merged. This is even one of the core reasons why Composer checks lockfile validity and integrity by hashing the definition file that it originated from.

In the end the approach you're trying to follow will causes more issues than it solves, because you're merging incompatible codebases with incompatible dependencies. The end result will crash at best, or behave erratically at worst. Upgrading code has to be done right - pick the code you're trying to backmerge, carefully reconstruct your dependencies, do a full composer update, and test test test. All other approaches will be highly volatile and prone to failure. And therefore not supported by Composer.

@dustyghost

This comment has been minimized.

dustyghost commented Nov 24, 2017

Yep, your points are valid. We resorted to composer update, and testing is always our priority. thank you for your reply.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment