Key Points

• Unless a globally installed package has no dependencies, it is now considered bad practice for installing packages used across multiple projects. This is because when the packages share the same space, dependency conflicts can occur. composer global require
Another solution is to install each command line tool into its own local project using
• , manually manage composer require or binary files. However, this can add complexity and tediousness. A suggested change to a global command may see a "global" but isolated project installed to a specific location, with its vendor and bin directories appearing in their usual location. $PATH
A new tool cgr (Composer Global Require) has been developed as an alternative to global implementation. It creates isolated installations for each package, avoiding global dependency issues. However, this tool is still in the proof of concept phase and may change. It is recommended to test it, but do not rely too much on it at this time.

We have discussed Composer best practices before, and I have always advocated using

when installing packages that can be used in multiple projects (especially command line tools). Then, one day, I came across this discussion. composer global require

In short, most people now seem to think global require is bad practice unless the globally installed package has no dependencies. Technically, this makes sense when one uses a single environment for all projects, but as I commented in that discussion, when each project uses a virtual machine or a properly isolated environment like Docker , this issue is irrelevant, and the overall situation will not actually cause damage.

OP The recommended solution to this problem is:

As an alternative, users should use

to install each command line tool into their own local project and manually manage their composer require or binary files (for example, by already existing from $PATH bin directory creates symbolic links). $PATH

For me, this is a totally unacceptable complication. Composer has always been the pride of PHP because it is easy to use and makes package management newbie-friendly - local

or global. Symbol links have to be created around (especially considering that non-symlinked operating systems like Windows) can add tediousness. Then, the OP further suggests changing how global commands work:

A "global" but isolated project can be installed to ~/.composer/global/[something]; its vendor and bin directories will appear in their usual locations, and the contents of the ~/.composer/global/[something]/bin directory can be mirrored in ~/.composer/vendor/bin (through symlink), or a better option might be ~/.composer/bin. The string [something] can be selected in a number of ways; the most straightforward way is org/project (although this means that there will be long paths like ~/.composer/global/org/project/vendor/org/project).

I totally agree with this approach, it seems to be the best of both worlds. Obviously, this may cause some backward compatibility issues, but that doesn't mean it won't happen in version 2.0 of Composer. Taylor Otwell further responds to this view below:

Full agree. It would be amazing to be able to install each composer globally installed package into its own quarantine directory and have its own quarantine dependencies instead of potentially conflicting with other globally installed packages.

After this, in the true open source spirit, OP then builds the alternative global implementation into a separate tool: cgr. Let's see how it works.

CGR – Composer Global Require Alternative

I will execute all the following commands on the Homestead Improved instance

To get started with CGR, we install it as a global package.

composer global require consolidation/cgr

If the bin folder of Composer is not in the PATH variable, add it:

echo "export PATH=$PATH:$HOME/.composer/vendor/bin/" >> ~/.bashrc
echo "export CGR_BIN_DIR=$HOME/.composer/vendor/bin" >> ~/.bashrc
source ~/.bashrc

The above commands use the path of Composer's global bin directory to extend $PATH environment variables (the default location on Homestead Improved - your location may be different). The second command configures the bin directory used by cgr, while the third command loads these changes. These will also automatically load each time the terminal interface is run as that user (in my case, using Vagrant via vagrant ssh).

Then you can access the CGR by running cgr, which should output the Composer's general help file.

Properly install the global Composer package

cgr phpunit/phpunit

On Homestead Improved, a useful alias is configured, where typing phpunit will expand to vendor/bin/phpunit, which is very convenient when installing phpunit for each project, so you can run it from the root folder. To test the global installation of PhpUnit, we need to delete this alias first (comment the corresponding line in ~/.bash_aliases), then exit the shell and re-enter so that the alias will reload. Then, running this new global installation of PhpUnit using version output should produce something like the following:

vagrant@homestead:~$ phpunit --version
PHPUnit 5.4.2 by Sebastian Bergmann and contributors.

Now let's try to install two incompatible packages.

cgr laravel/installer
cgr wp-cli/wp-cli

Of course, they can all be installed normally. Let's check if they work.

composer global require consolidation/cgr

Everything goes well! Global packages that previously conflicted due to dependency mismatch can now coexist side by side and can be used throughout the operating system without any problems!

What shouldn't/can't do this tool?

In some cases, you may want to install the Composer plugin. As stated in the Restrictions section, these plugins are not available globally in all global projects because CGR installs each global package into its own folder and has its own dependency tree. So if you want to install a plugin that changes the common behavior of composer, you should still use composer global require instead of cgr. For example, CGR itself is such a plugin.

What's next?

Test, test, test! If you are a frequent user of the global require command, I highly recommend that you test this new tool and give Greg Anderson some feedback on how much it meets your global needs and whether there are any improvements.

Please note that this tool is currently only a proof of concept, and implementation may or may not be renamed, repackaged, eventually integrated into the core of Composer, and more. In other words, use it as much as you can, but don't over-rely rely on it for the time being.

While your global package is installed, why not tell us what you think about composer global require? Is it as harmful as many people now think? Or is it just a matter of being cautious and having an isolated development environment? What else? Please express your comments below!

FAQs about Composer Global Require

Why is it considered harmful to use Composer's global requirement?

Composer's global requirement is considered harmful because it can lead to dependency conflicts. When you install packages globally, they all share the same space, which means they share the same set of dependencies. If two packages require different versions of the same dependencies, it can lead to conflicts and errors. It is recommended to install its own set of dependencies for each project to avoid such problems.

What is the alternative to Composer global require?

Do not use Composer's global requirement, you can create a new Composer project for each tool you need. This way, each tool will have its own set of dependencies, thus reducing the risk of conflict. You can also use tools like cgr, which creates isolated installations for each package, thus avoiding global dependency issues.

cgr How can I help avoid global dependency issues?

CGR (Composer Global Require) is a tool to create isolated installations for each package. This means that each package and its dependencies are installed in its own separate directory, avoiding the risk of conflicts between dependencies of different packages. This makes it a safer alternative to using Composer global require.

How to install and use cgr?

To install cgr, you can use the command composer global require consolidation/cgr. After installation, you can use cgr like you would use Composer's global requirement. For example, to install a package, you can use the command cgr require package-name.

What is the difference between local installation and global installation in Composer?

In Composer, local installation means that the package and its dependencies are installed in the project's directory. This is the recommended way to install packages, as it avoids dependency conflicts. On the other hand, global installation installs packages and their dependencies in a global directory, which can lead to conflicts if different packages require different versions of the same dependencies.

How to manage global dependencies in Composer?

Managing global dependencies in Composer can be challenging due to the risk of conflict. However, tools like cgr can help by creating isolated installations for each package. You can also manage global dependencies by creating a new Composer project for each required tool, ensuring that each tool has its own set of dependencies.

Can I use both local and global installations in Composer?

Yes, you can use both local and global installations in Composer. However, it is recommended to use a local installation where possible to avoid dependency conflicts. If you need to use packages globally, consider using tools like cgr to create an isolated installation.

What are the risks of incorrectly managing dependencies in Composer?

Incorrectly managing dependencies in Composer can lead to conflicts and errors. If two packages require the same dependencies of different versions, it can cause difficult to debug problems. It can also cause unexpected behavior of the application, as different versions of dependencies may have different functions and behaviors.

How to resolve dependency conflicts in Composer?

To resolve dependency conflicts in Composer, you can try to update the package to the latest version, as this may resolve the conflict. If this doesn't work, you may want to rethink the package you are using and find alternatives that don't have conflicting dependencies. Tools like cgr can also help by creating isolated installations for each package.

How to keep Composer dependencies up to date?

To keep Composer dependencies up to date, you can use the composer update command. This updates all packages to their latest version based on the version constraint specified in the composer.json file. You can also use the composer outdated command to see which packages are available for newer versions.

The above is the detailed content of Composer Global Require Considered Harmful?. For more information, please follow other related articles on the PHP Chinese website!