Composer command line interface and commands (Part 4)

Introduction

This is the fourth part of the Composer command line interface and commands.

#outdated.

The “compose outdated” command is a composer command used to show the list of the current version of installed packages as well as their latest version if available. This command is similar to the “composer show -lo” command.

Theses outdated packages are displayed with the following color codes:

• green (=): This implies that the dependency is in the latest version and is up to date.
• yellow(~): This signifies that dependency has a new version available that includes backward compatibility breaks according to semver, so upgrading is at your own risk, as a lot of works may be required.
• red (!): This is very critical, indicating that dependency has a new version that is semver-compatible, and you are advised to upgrade it.

Options

• --all (-a): With this flag, all the installed packages will be displayed, not just the outdated ones.
• --direct (-D): This displays only packages that are our direct dependencies.
• --strict: This will cause the return of a  non-zero exit code if any package is outdated.
• --minor-only (-m): This will display packages that have minor SemVer-compatible updates.
• --format (-f): This is an output formatter, it allows us to choose between json and text output 

#browse / home

The browse (also called  home) opens a package's repository URL or homepage in our browser. Some optional parameters can also be used with this command

Options

• --homepage (-H): This opens the homepage instead of the URL of the repository.
• --show (-s): This  show only the homepage or repository URL if available.

#suggests

Lists all the suggested packages by the currently installed packages. We can pass an optional package name, to format and limit the output to only the package names given. The name should be in the following format: “vendor/packages”.

We can use  the --by-package or --by-suggestion flags to group the output by the package offering the suggestions or the suggested packages respectively.

Also,  the --verbose (-v) flag is used to display the suggesting package and the suggestion reason. Therefore, this implies --by-package --by-suggestion, will show  both lists.

composer suggests vendor_name/package_name  --by-package –-by suggestion

The suggest command can also be combined with some optional parameters as shown:

Options

• --by-package: This groups the output by suggested packages.
• --by-suggestion: Also, groups output by suggested package.
• --no-dev: This will exclude suggestions from the  require-dev packages.

#depends (why)

The composer depends on command tells us which packages depend on a certain other package.

composer depends doctrine/lexer

The above code snippet will display all the packages which “doctrine/lexer” depends on.

We  can also  optionally specify a version constraint after the package to limit the search results.

Adding  the --tree or -t flag to show a recursive tree of why this very package is dependent on a certain package.

composer depends doctrine/lexer -t

Some optional parameters can also be passed to the composer depends on command as shown below

• --recursive (-r): This command resolves recursively resolves up to the root package.
• --tree (-t): This nests across, printing why a package depends on the other.

#prohibits (why-not)

The composer  prohibits command tells us which packages are preventing a given package from being installed.

composer prohibits symfony/symfony 3.1 

We can specify a version constraint to verify whether upgrades can be done on project, and if not why not.

NB: We can also specify platform requirements, to discover platform requirements for instance to check whether you can upgrade your server to PHP 8.0 we say

composer prohibits prohibits php:8

Using the depends command, we can do a  recursive lookup, which will display all packages depending on the packages that cause the conflict, some optional parameters can also be passed as shown

Options

• --recursive (-r): Recursively resolves up to the root package.
• --tree (-t): Prints the results as a nested tree, implies -r.

#validate

The composer validate command is used to validate the validity of composer.json files. It is highly recommended that this command shell be exicuted before we commit the composer.json file.

composer validate

Some optional flags can be passed to the composer validate command as shown below:

Options

• --no-check-all: This flag will cause the composer not to emit warning if requirements in composer.json are not met but rather use unbound version constraints.
• --no-check-lock:  This will cause no emission of errors if composer.lock exists and is not up to date.
• --no-check-publish: This flag will also prevent an error from emitting if composer.json is unsuitable for publishing as a package on Packagist but is otherwise valid.
• --with-dependencies: This will validate the composer.json file as well as the composer.json of all the installed dependencies.
• --strict: This will return a non-zero exit code for all  warnings as well as errors.

Previous: Composer command line interface and commands (Part 3)
Next: Composer command line interface and commands (part 5)