Here is the definitions from the docs:
The require command adds new packages to the composer.json file from
the current directory. If no file exists one will be created on the
fly. After adding/changing the requirements, the modified requirements
will be installed or updated.
If you do not want to choose requirements interactively, you can just
pass them to the command.
I can't seem to understand the purpose of the require command and the difference from install. Can you elaborate on that?
And here is the example of using the command:
composer global require "fxp/composer-asset-plugin:~1.0.3"
Can you tell me what's the difference from:
composer global install "fxp/composer-asset-plugin:~1.0.3"
It's just a convention. There might be some fallbacks in other commands for common people missuses, but every command is optimized for a different feature. It's just better user experience.
Same goes for similarity of composer install and composer update.
As for conventions, in order of common workflow:
composer install is for installing all packages of new application (all mentioned in composer.json), use: composer install
composer require is for adding a new package, use: composer require symfony/symfony
composer update is for updating current dependencies, use: composer update
composer require->It will write the modules in composer.json file and install the module.
composer install->It will install the modules which are already present in the composer.json file.
Related
According to docs, composer install (composer update too, since it includes install script), among other things, downloads the requirements and puts these packages inside the vendor directory: https://getcomposer.org/doc/01-basic-usage.md#installing-dependencies :
It then implicitly runs the install command. This will download the dependencies' files into the vendor directory in your project.
What the docs don't say is: we often write the following in composer.JSON...
"require": {
"php": "^8.0",
... so if we try to apply what the docs say, it means that Composer would download the PHP interpretor (a package available in Packagist for example) and put it inside the vendor directory, when we run either composer install or composer update. What is the interest of putting a PHP interpretor inside a site's folder (here, vendor)?
But we know it doesn't do that. It won't download any PHP interpretor. It won't obviously put it inside the vendor directory. Instead, it will just check the server's PHP interpretor's version and returns a fatal error or something else if this version doesn't match the requirement's version.
So does it mean that in the Composer's install and update scripts, there is an exception made for PHP when treating the require's lines in the composer.JSON file?
In composer there's a special exception for require php, it only checks if your system's PHP version meets the requirement.
It's in the composer website under Package links: https://getcomposer.org/doc/04-schema.md#package-links.
Its not literally written though, its quite hard to find in the composer documentation.
If your require contains something like with
"php": "^8.0",
"ext-json": "*",
this does not mean: Install PHP or the JSON extension through Composer, but require that PHP and that extension in the given versions are already installed. That's what the documentation at https://getcomposer.org/doc/04-schema.md#package-links tells you:
require and require-dev also support references to specific PHP versions and PHP extensions your project needs to run successfully.
A regular expression that matches all such platform requirements can be found at https://github.com/composer/composer/blob/9ba042ded8b26230d33ebceb692bf29111d51ba4/src/Composer/Repository/PlatformRepository.php#L34 - currently, it contains:
const PLATFORM_PACKAGE_REGEX = '{^(?:php(?:-64bit|-ipv6|-zts|-debug)?|hhvm|(?:ext|lib)-[a-z0-9](?:[_.-]?[a-z0-9]+)*|composer-(?:plugin|runtime)-api)$}iD';
...which matches:
PHP runtimes in several versions
HHVM, a virtual machine that runs a forked version of PHP
all kinds of extensions and core libraries, like ext-json or lib-bz2
Composer itself, as some packages require special features of Composer v2 which were not available in v1
All lines in require section of composer.JSON are not packages available on a repository like Packagist: indeed, we can put some "virtual packages" inside this require section (https://getcomposer.org/doc/01-basic-usage.md#platform-packages).
php is one of these virtual packages. So Composer treat the following line...
"require": {
"php": "^8.0",
... as a virtual package (other name: "plateform package"), and not a package that could be put in vendor.
Then, if we extend a little the following definition of require...
Map of packages required by this package. The package will not be installed unless those requirements can be met.
(https://getcomposer.org/doc/04-schema.md#require)
..., then we can say that "if server's PHP interpretor's version doesn't meet the requirements versions, then Composer will raise a fatal error or something like that.
**Conclusion: being seen as a "virtual/plateform package" by Composer, php won't be installed (put) in vendor directory. It will just make Composer to check if server PHP version matches or not the requirements (if not, an error will be raised). This behavior is different than for other packages that would be, them, downloaded from for example Packagist and installed (put) inside vendor directory. **
Is there a way to composer require some/thing without actually pulling the package? In my workflow, it would hasten things if I knew a command to just check version requirements and update composer.json without actually doing anything with regard to the vendor directory.
You can use --no-update switch to avoid updating and installing new dependencies - it will only add new dependency to composer.json.
composer require --no-update symfony/symfony
But since require does not check if required package can be installed (it always pick the newest version compatible with your PHP as a constraint, without checking if it will be possible to install), this can leave composer.json in non-installable state.
It will also not update composer.lock so composer install may ignore your new dependency. So this is probably a bad idea unless you want to do something with it before you commit new composer.json.
You may try to use --dry-run switch to test what will happen after composer update - you will be able to check if composer.json is installable, but composer.lock still will be out of date.
composer update --dry-run
I've currently installed a package "watson/sitemap". Now, I want to remove it without using "composer update" since it will update other packages which I don't want.
Any help would be much appreciated.
UPDATE: Composer 2 is now out, and it seems to be smart enough to handle the recursion. You need only remove the offending package.
I recently needed to do this. Here's a real-world example. This is pretty hacky. You could script this by using Composer's PHP classes or by parsing the composer.lock file, but this is a manual process you can follow.
1. Remove the unwanted package(s)
composer remove --no-update illuminate/mail
composer update illuminate/mail
2. Look for orphaned dependencies
composer show -N | xargs -n 1 composer why | grep "There is no installed package"
Output (something like this):
There is no installed package depending on "erusev/parsedown"
There is no installed package depending on "swiftmailer/swiftmailer"
There is no installed package depending on "tijsverkoyen/css-to-inline-styles"
3. Remove orphaned dependencies
composer update erusev/parsedown swiftmailer/swiftmailer tijsverkoyen/css-to-inline-styles
4. Rinse, repeat
Repeat steps 2 and 3 until you've found all the orphans.
Clarification: If you use the --no-update flag, you won't upgrade packages... however (as of writing, early 2020) it also does not remove orphaned dependencies. You're not telling it not to "upgrade". You're telling it not to update any of the installed (composer.lock) dependencies. Big difference. This is why you have to find them and manually "update" them out of your project.
Right way:
composer remove watson/sitemap --no-update
From CLI Docs:
The remove command removes packages from the composer.json file from
the current directory.
php composer.phar remove vendor/package vendor/package2
After removing the requirements, the modified requirements will be
uninstalled.
Hack way:
Remove the entry from composer.json then run
composer update watson/sitemap
This will remove a package totally from composer.lock and /vendor
I'm not sure this is possible. To restate your question. You have watson/sitemap in your composer.json, you've executed a composer update to download the package and it's dependencies. Now you want to remove the package but leave dependent packages in place?
I'm not sure there's a good way to do this, you'll have to run composer update at some point, which will just download it again. If my interpretation is correct, maybe your solution is to just add the other packages that you need that you don't want removed when you get rid of watson/sitemap, possibly sloppy/paste it's dependencies into your composer.json file?
I use
composer remove package-name --no-update-with-dependencies
Works imho
I added a package in the require block of my composer.json.
I do a composer install and it says Nothing to install or update.
In my understanding, composer update would work but I shouldn't do that because it updates the versions of the other packages to the latest, but I haven't tested my code on them.
How do I install that new package?
The Command Line.
You don't have to add the new packages manually to your composer.json file and then do a composer install or update. Use The Command Line
Installing new packages from the command line automatically adds it to your composer.json file and it does not update previously installed packages.
From the project root, simply run:
composer require package/name
Hope it helps
For future readers, if you have already added package(s) to your require block in composer.json, it's as simple as listing them all after the update command to exclude existing packages from being updated. First, simulate update to ensure you're happy with the result:
composer update --dry-run vendor/project vendor2/project2
If okay, run it again with the --dry-run argument removed.
You can see the output of updating new/specific packages is different from that of:
composer update --dry-run
Your composer.lock file should be on version control or otherwise backed up so you can restore it & revert all packages in the event of failure.
Using composer require will also update other dependencies.
We can install a new package without updating anything else like this:
composer require package/name --no-update
this will add your package to composer.json, leaving composer.lock intact.
composer update package/name
this will now install/update your new package, adding it to composer.lock. This will not update any other dependencies.
I'm trying to make composer update only newly added packages to composer.json i.e when I manually add a package dependency to the composer.json file, it should update the composer.lock file only for the new package; the rest of the packages should be at the same version as before. I tried running composer update --lock but I don't think it does what I'm trying to achieve and it took a lot of time to finish. I checked the commands on composer's documentation but can't find one to achieve my wish. Any advice or workaround will be appreciated.
Note: I'm using Laravel Forge, so there is a 2 minutes deployment limit.
In order to install only new packages with composer you should run
composer install
Because composer update will install your new packages but will update and all the other already installed packages.
You can specify the name of the package as an argument to the update command. This will perform a partial update: composer update the-package/you-want-to-update
I think your question is related to your (guessed) current workflow: To add a new package you edit the composer.json file and then run composer update - wishing to only add/update that new file.
If that is true, here is the solution:
composer require new/package will add the newest possible version (taking into account the currently installed packages) of the new package. Benefits: Only one command line, and no fiddling with JSON content.
If you already know which version you want, you could also run composer require new/package:^2.1.25#beta (or whatever version and stability level you want - this example is exaggerating a bit). If this version is incompatible with existing packages, nothing will get installed, everything will get rolled back, and you get an error message.