Download Composer.lock File
Tamsyn Gradney
When you run the composer install command, it checks the composer.lock for the exact locked package version which has been already installed previously, during the previous composer install.
When you run the composer update command, the composer checks if there is a newer package, and if there is, downloads the new package version and updates the composer.lock content with the new version.
TIP: On production servers, always use composer install and never composer update, because sometimes updating packages without testing could break your application. Use composer update locally, then commit the updated composer.lock to the repository, and then run composer install on the production server.
Background:
I recently started using Composer to update my websites. After hours of attempts to update Core to 8.4.0 from 8.3.7, I finally did it the old-fashioned way and just restored my original composer.json and composer.lock files. Now I am dipping my feet back into the Composer pond to try what should be an easier update. From Symfony 2.8.26 to 3.3.1. Here is what I have done:
How do I resolve this?
I can't seem to find a clear answer as to whether I must modify my composer.lock or run a more explicit composer update command. Any help would be appreciated.
So i would remove "symfony/symfony": "3.3.1" and delete the composer.lock file and vendor dir, and let composer resolve the dependencies for you and re-fetch all the required files for vendor dir by running:
Sounds like some one has changed the composer.lock on the staging server. Each time you resolve a merge conflict a new commit is made.In case you don't push the new commit, each time you run git pull a new conflict will be caused.
OWASP dependency-check includes an analyzer that scans composer.lock files to get exact dependencyversion information from PHP projects which are managed with Composer.If you're using Composer to manage your project, this will only analyze the composer.lock filecurrently, so you'll need to run composer install to have Composer generate this file.
You shouldn't update the composer.lock manually because this one is automatically generated. You can add modules in your composer.json there in the require and then run the following composer command:
Then you can track the changes through git because besides your composer.json the composer.lock will be automatically updated and pull them to your live or staging environment. After the pull you should run the command
If you use composer install it will only install the versions as given in the composer.lock and if you use composer update it will try to update to the latest version as possible based on the composer versioning.
composer.lock should always be committed to the repository. It has all the information needed to bring thelocal dependencies to the last committed state. If that file is modified on the repository, you will need to runcomposer install again after fetching the changes to update your local dependencies to those on that file.
The composer.lock file should not be listed in your .gitignore file because it must be committed for individual sites created from your custom upstream. Use the command below to avoid accidentally committing a composer.lock file when working directly with your custom upstream.
The command has the same effect as ignoring the file in the top-level .gitignore file, except that the exclude file is not saved in the repository when you push changes back to the remote origin. You must re-run this command every time you make a new local clone of your upstream if you would like to protect against inadvertently committing a composer.lock file.
You may need to pin specific versions of your dependencies in your Custom Upstream. This is normally done with the composer.lock file. However, including the composer.lock file in the root of the Custom Upstream causes merge conflicts with your downstream sites. You can use the upstream:update-dependencies composer command to solve this problem.
The existence of the composer.lock file in the VCS repo prevents PHPUnit from being added as a dependency because its version and its dependencies vary depending on the version of PHP that's in use, meaning the lock file also needs to vary. If the dependencies are installed (and the lock file is created and committed) using PHP 7.1 or higher then a user trying to install the dependencies using PHP 7.0 or lower will not be able to proceed because the PHP version dependency for PHPUnit 7 that's declared in the lock file won't be met.
One of the major reasons to have a composer.lock in the first place is to make sure we get the exact same build in two composer install calls. Drupal and Joomla, both similar software as us and adopted Composer throughout the software before us, still keep their lock files in the repo.
Bottom line is that, I think we should keep the composer.lock file considering the tendency of us using composer dependencies in WordPress such as sodium_compat, polyfills, etc. It's considered a good practice to use lock files in major software, and I think we should follow suit.
I'd very much like to revive this ticket as the existence of the committed composer.lock file is - as @johnbillion states quite eloquently above - a blocker for easily testing cross-version PHP.
You may say, but what about managing things like WordPressCS ? We don't want builds to start failing randomly because WPCS released a new version....
And yes, you are right to bring that up. Tools like WPCS should be fixed to a specific version when we remove the composer.lock file to prevent random build failures on a new release.
We should probably also add a fixed dependency to a specific PHP_CodeSniffer version as otherwise - with WPCS allowing for a wider range of PHPCS versions -, a new PHPCS release may have a similar effect.
With an eye on those upcoming changes, which will allow us to run the tests on the most appropriate PHPUnit version for each supported PHP version, it is opportune to switch to using a Composer-installed version of PHPUnit for all PHP versions supported by WordPress. Previously this was not possible without additional conditional update commands being run, due to the composer.lock file being in place and being locked at PHPUnit 7.5.20.
Just wanted to add that the reason you should do so is that if you don't include the composer.lock file in your repo you will need to update packages with composer update which consumes much more time than composer install at every run and same versions of packages across all installs are not guaranteed.
Ok, you have installed a Yii 2 basic or advanced app for the first time and completed the post install steps. You have picked up a few extensions to install for the first time as well. You would already see a composer.lock file in your application root folder.
For composer audit to work properly the packages must be installed by default. But if you use --locked (composer audit --locked) then the audit is based just on the composer.lock file and there's no need to install the packages beforehand.
Applications that do not use a composer.json, or where composer.lock contains no requirements for package php even in any dependent package, will pick the latest possible version of either PHP 7 or PHP 8 on the heroku-20 stack, and PHP 8.1 or later on the heroku-22 stack.
You may select the runtime(s) to use via Composer Platform Packages in composer.json. Upon a push, Heroku will read the necessary information from composer.lock, if present, and fall back to composer.json otherwise.
This means that a requirement of composer.json (or any dependency) for e.g. ext-mbstring would not lead to the installation of the native ext-mbstring extension if the symfony/polyfill-mbstring package is also present in composer.lock, as symfony/polyfill-mbstring declares ext-mbstring as provided:
There are a number of situations where we need to update the bundled composer.json] in core. When we upgrade, for a given branch, the phpunit or the behat-extension versions... we also have to update the composer.lock file, in order to guarantee that all the tests will run in a stable, verified environment.
Copy the command from Packagist and paste it onto the terminal. This will either create the composer.json, composer.lock files and the vendor directory or update them if they already exist
If you are creating a project, you definitely want to commit composer.lock to git. This ensures that everyone - you, your co-workers, your CI server and your production server - is running the application with the same dependencies versions.
At first glance, it may sound superfluous - you are already using a specific version in the constraint, as mentioned in the tip #3. But no, there are also the dependencies of your dependencies which are not bound by these constraints (e.g. symfony/console depends on symfony/polyfill-mbstring). So without committing the composer.lock, you won't get the exact same set of dependencies.
Imagine that the acme/my-library uses monolog/monolog as a dependency. If you have committed a composer.lock, everyone who is developing the acme/my-library would be using an older version of Monolog. But when the library is finished, and you use it in a real project, a newer version of Monolog may be installed, and it may not be compatible with the library. But you didn't notice it before, because of the composer.lock!
If you add a new dependency to composer.json (and composer.lock) and before your branch is merged, there is another dependency added in master, you need to rebase your branch. And you will get a merge-conflict in composer.lock.
You should never try to resolve this conflict manually, because the composer.lock file contains a hash of dependencies defined in composer.json. So even if you resolve the conflict, the resulting lock file would be incorrect.
df19127ead