Composer Command Line Interface and Commands(Part 1)

Introduction

In the previous tutorials we have already used the command line to punch some composer commands, and get some things done using composer, in this tutorial, we will look at all the available composer commands and their uses.

In the command line, to get or to access these composer commands, simply type “composer” or “composer list” to see a complete list of composer commands. The “—help” flag gives you more details about a command.

Composer makes use of Symfony/console, this allows us to call commands by their short name, if they are not ambiguous as shown in the snippet below:

composer dump

The above code snippet is a short form of the composer command “composer auto-dump”

Composer Commands

#Global Options:

 The global options are available on every composer command. They are used to further describe a command as shown below:

composer --help

The above command will display all the commands in the composer, just because of the global option

“ --help”.

• --verbose (-v): This increases the  verbosity of messages.
• --help (-h): This command displays help information.
• --quiet (-q): The do not output any message command.
• --no-interaction (-n): The do not ask any interactive question.
• --no-plugins: This disables all plugins.
• --no-cache: this disables the use of the cache directory.
• --working-dir (-d): If specified, it forces composer to use the given directory as working directory.
• --profile: This display timing and memory usage information
• --ansi: Used to force ANSI output.
• --no-ansi: Used to disable ANSI output.
• --version (-V): It displays this application version.

#Process Exit Codes

Process exit codes are codes generally used to exit a process, they include

• 0: OK, when a process completes successfully
• 1: Generic/unknown error code
• 2: Dependency solving error code

#init:

The init command is used to initialize composer in a project. This is shown in the following snippet below

composer init

This command has the following options:

• name: This is the name of the package.
• description: A short description about of the package.
• author: The package owners name.
• type: Defines the type of package.
• homepage: The URL homepage of the package.
• require: Some packages to require a version constraint. It should be in format “proj/paa:1.0.0”
• require-dev: Packages required for development
• stability (-s): A value for the minimum-stability field.
• license (-l): The type of license the package has.
• repository: Where can the package be located. A repository specifies where a package is hosted.

#install / i

The “install” command reads the “composer.json” file from the projects root  directory, then resolves the dependencies, and installs them into the “vendor” folder.

composer install

In the presence of a “composer.lock” file in the current directory, it will use the exact versions from there instead of resolving them. This ensures that everyone using the package will get the same versions of the dependencies.

If there is no “composer.lock” file, Composer will create one after dependency resolution.

The “composer install” command has the following optional parameters:

• --prefer-source: Packages can be downloaded in two way: source and dist. The Composer uses the dist by default for stable versions of packages. The source is used to download packages from version control systems.

  composer install  --prefer-source

  In the above code snippet, the composer will download from the version control source if there is one. This is usually used for bug fixes.
• --prefer-dist: This is the opposite of --prefer-source, Composer will install directly from Packagist if possible. This is the default composer behavior. Thus, the command “composer install” and “composer install –prefer-dist” gives the same result.
• --dry-run: This command allows you to simulate an installation process without installing a package.

  composer install --dry-run

• --dev: This command installs packages listed in the “require-dev” block of the composer.json file. This is actually the composer default behavior.
• --no-dev: This command causes composer to skip installing packages listed in require-dev. Also, the autoloader generation skips the autoload-dev rules.
• --no-autoloader: This installs the packages without generating the autoloader file.
• --no-scripts: This command skips the execution of scripts defined in composer.json.
• --no-progress: This removes the progress display that a times  mess with some terminals or scripts where backspaces are not allowed.
• --no-suggest: This installs the packages without giving suggestions to other recommended packages.
• --optimize-autoloader (-o): Convert PSR-0/4 autoloading to class map to get an optimized autoloader. This is recommended for the production environment, as takes quite some time to complete, so this is not a composer default behavior.
• --classmap-authoritative (-a): This autoload classes from the classmap thereby. implicitly enabling --optimize-autoloader.
• --apcu-autoloader: This uses APCu to cache found/not-found classes.
• --ignore-platform-reqs: This forces composer to ignore system requirements for packages. Thus, it ignores packages even when the requirements are not met.

  composer install -–ignore-platform-reqs

Previous: The composer.json schema
Next: Composer command line interface and commands (Part 2)