Lecture
Composer is an application level package manager for the PHP programming language that provides dependency management tools in a PHP application.
In simple words. all that you did not write and others wrote (in other modules) will be installed and updated.
Composer's standard workflow:
This is the correct way to use the composer. If you use a linker to deploy your dependencies in a production environment (as many people do), based on this workflow, you can mistakenly assume that you deploy your composer.json update to production and run composer update again. This is the wrong way to use the composer.
What really happens at startup is that composer update is that it downloads the latest version of your dependencies, as indicated by composer.json.
What you really need to do is deploy your updated composer.lock and then restart composer install. You should never run composer update on production. If, however, you deploy a new composer.lock with new dependencies and / or versions (after running composer update in dev), then start the composer install composer, update and install the new new dependencies.
Whenever a composer creates a new composer.lock, it blocks you until a certain set of dependencies and the latest versions of these dependencies can be solved.
This means that if you composer.json specify the packet / packet: 1. *, and it installs packet 1.2, packet 1.2 will be included in your lock file.
Since then, when you run composer install, you will receive only packet1.2, even after the output of packet 1.3.
Here is the main workflow:
Not too hard.
Now we can return to the question that caused this post. Since we never run composer update in production, it follows that whenever we launch it, we will be in our development environment, and now the automatic inclusion of the --require-dev flag composer update makes sense.
If you are still not happy, you can ignore all of this and add the --no-dev flag to change behavior.
Now we’ll watch briefly and clearly about all the Composer commands.
| team | description |
|---|---|
| composer require vendor / package | Adds the required package to the composer.json file and installs it in your project. The require command modifies the composer.json in the current folder. If a package requires dependencies, they will be installed or updated. And also will be updated composer.lock. |
| composer install | If the composer.lock file does not exist, resolves the dependencies based on composer.json and creates it. Next, it analyzes the composer.lock file, downloads and installs the versions of the packages specified in it. The option --no-scripts is useful for bypassing running scripts specified in the pre- and post-settings. |
| composer update | Updates your dependencies to the latest versions and updates composer.lock. The update command resolves dependencies to get the latest versions of packages dependent on each other. |
| composer update --lock | Sometimes, you may get this warning: If you’re getting outdated, you can’t get outdated.This can happen after you manually edited composer.json (added or modified description, authors, extra, etc.). Even if your changes are insignificant for Composer, it detects that the md5sum file is changed, and warns that these changes are not taken into account in the composer.lock file. Therefore, to suppress this warning, you can simply run the update --lock command to update the lock file without updating the packages themselves. |
| composer dump-autoload --optimize | If you need to update the bootloader, since new classes have appeared, you can issue the dump-autoload command to avoid installing or updating packages. Use the --optimize switch to convert PSR-0 to autoload as for a classmap so that the autoloader is the fastest. This is highly recommended for production (you can get a 20% increase) , but it may take a little time to run, so this is not currently done by default. You can also use the dumpautoload alias. |
| composer about | Summary of Composer. |
| composer archive vendor / package | Create an archive for the specified package. The command can also be used to archive the entire project without excluded / ignored files. |
| composer browse | Nickname for home, opens the URL of the package or its home page in the browser. |
| composer clear-cache | The alias of the clearcache command clears the internal cache of Composer packages. |
| composer config --list | Allows you to edit some basic Composer settings either in the local composer.json file or in the global config.json file. |
| composer create-project vendor / package dir / | Create a new project from the specified package in the specified directory. |
| composer depends vendor / package | Tells you what other packages depend on the specific (specified) package. You can specify which types of links (require, require-dev) should be included in the listing. By default, both are displayed. |
| composer diagnose | If you think you have found a mistake, or if something behaves strangely, you may want to run a diagnostic command to perform automated checks for many common problems. |
| composer global | The global command allows other commands such as install, require or update to run as if you ran them from the COMPOSER_HOME directory. It can be used for installing command utilities globally. If you add $ COMPOSER_HOME / vendor / bin to the $ PATH variable of your environment, then launching the utilities will become quite simple. For example, install php-cs-fixer: $ php composer.phar global require fabpot / php-cs-fixer: dev-master Now the executable file php-cs-fixer is available globally and you can run it from anywhere (of course, if you set up your PATH variable). |
| composer help [command] | Displays help for all other commands: composer.phar help install. |
| composer init | Creates a basic version of the composer.json file in the current directory. When you run the command, Composer will interactively query the field values to fill in, using smart defaults for some fields. |
| composer licenses | Show dependency license information. |
| composer list | Displays a list of valid commands. |
| composer remove | Removes a package from the require or require-dev sections: remove vendor / package vendor / package2. |
| composer run-script | Run manually the scripts declared in composer.json. Just pass the name of the script and, if necessary, --no-dev to disable the dev mode. |
| composer search keywords | Search for packages. The search command allows you to search the repositories of the current project (see the "repositories" section in composer.json). Usually it will only packagist.org. You just need to pass the search word to the team. |
| composer self-update | Update composer.phar itself to the latest version. Running the self-update command can solve some problems and save you time. You can also use the self-alias selfupdate. |
| composer show | List of all installed packages (composer show). List of all available packages (composer show - all). Info about the specified package or its specific version (composer show vendor / package [version]). |
| composer suggest | Displays a list of all packages proposed installed. Optionally, you can transfer one or more package names in the format vendor / package to limit the output to only those that were suggested. |
| composer status | If you often have to modify the code of your dependencies, and they were installed "from source" (see the option of the require command - prefer-source), then The status command will allow you to check if you have local changes to any of them. |
| composer validate | Checks the file composer.json. You should always run the validate command before committing your composer.json and before installing the release tag. This command will check it for errors. |
Comments
To leave a comment
Running server side scripts using PHP as an example (LAMP)
Terms: Running server side scripts using PHP as an example (LAMP)