In a recent article Théo Fidry covers a topic that's become common with the use of Composer and various PHP packages: managing dependencies.

When you are creating a PHP application or library, you usually have 3 kinds of dependencies:

Hard dependencies: what your application/library needs to be able to run

Optional dependencies: for example a PHP library can provide a bridge for different frameworks

Development dependencies: debugging tools, test frameworks…

He then works through several of the issues involved with using each including having too many dependencies, untestable dependencies and conflicts. He then counters these with some helpful suggestions around them including the use of phars and using multiple repositories to break down the package and make it easier to manage their dependencies.

Robert Basic has shared a quick tip for the Composer users out there (you do use Composer, right?) showing how to exclude certain packages from updates without having to whitelist packages all the time.

Given that Composer has no --exclude flag or similar, the only other option is to create a list of packages we allow to be updated, excluding the ones we don’t want to be updated. We need to create a whitelist.

Creating it manually would be a PITA though, especially if there’s a lot of packages to include or exclude. CLI to the rescue!

He includes a command that grabs the packages from the current composer info listing (using grep, sed, cut and paste). He walks through the command showing how it works to pull the package information out. With the help of the -v option for grep it's easy to remove certain items from the list (blacklist) and to provide a string back to composer that can then be used to update only the remaining packages.

Alison Gianotto has an article posted to her since basically answering the "now what?" question resulting from you running Composer as root on your system.

Composer is a PHP dependency manager that’s used in just about any modern PHP application, and it works similarly to how Bundler works for Ruby.

Even though Composer itself gives you a warning about not running it as root, lots of people disregard this warning and run it as root anyway. We run into this issue a lot on my open source asset management project, Snipe-IT, so I figured I’d write up how to fix this if you inadvertently (or advertently) ran composer as root.

She starts by describing the difference between "installing Composer as root" and "running the Composer install as root" (two very different things). She points out that, while Composer tries to prevent the second but permissions errors sometimes cause people to move forward as root anyway, despite the warning. She then shows how to fix the permissions issues so it can be run as a normal user, updating the files in .composer for the root account and re-running the install.

A quick note on methodology, because all these stats are imperfect as they just sample some subset of the PHP user base. I look in the packagist.org logs of the last month for Composer installs done by someone. Composer sends the PHP version it is running with in its User-Agent header, so I can use that to see which PHP versions people are using Composer with.

He then shares the results of the statistics including the total number of users for each version of the language and the difference in just the last 6-7 months. PHP 7.1 has pulled out as a front-runner with PHP 7.0 coming in closely after. He also shows some historical data showing the decline of the 5.x versions and the rise of 7.x versions over the past years. The post ends with information about the percentage of requirements in packages with 5.6 taking the lead but not by much.

In this article, we'll go ahead and explore the package management feature in the Laravel framework. In the course of the article, we’ll go through a real-world example to demonstrate the purpose of the article.

Package management in Laravel is an important feature that allows you to bundle a piece of functionality so that it can be distributed easily. Moreover, you could always publish your package to repositories like Packagist and GitHub that allow other developers to benefit from your package.

They start by listing out the files that will be involved in the tutorial (requiring a pre-set up Laravel application) and a basic knowledge of the application's structure. The article then walks through setting up some of the prerequisites and the creation of your own custom package. They include the updates to the routing, controller, updates to the view and changes in the service provider handling.

Rob Allen has a quick post to his site that could help out Composer users when they need to transition to a git copy of a repository rather than an export.

I'm adding a new feature to ZF's Problem-Details component and it's easiest to do this within the context of the application I'm developing.

The component lives in vendor/zendframework/zend-problem-details and was installed using composer require so doesn't have its own git repository as the distribution zip file was used to install it.

He shows how to use the built-in --prefer-source option for Composer to pull down a clone of the repository rather than the copy. This allows you do develop right in the same environment without having to re-clone the repository somewhere else and work from there.

If you’ve inherited a legacy code base, you may find it does not use an autoloader and has an idiosyncratic directory and file hierarchy for its Classes, Interfaces or Traits. Worse yet, it might not use name spaces consistently or at all. So you can’t use a posting on Twitter. [...] In this post, I’ll detail the three solutions I found: using Composer’s classmap autoloader, Symfony classmap generator (deprecated), or Zend Framework’s ClassFileLocator.

He then goes through each of the tools mentioned above and shows how to implement them to locate class files and auto-generate the autoloader files. They each have slightly different methods of getting the class files from the current code but they all end up with basically the same result: a classmap (set of relations between classes and the files they live in).

On the Laravel News site there's a new post that continues their series about building applications with Composer. In this latest post they talk about the "other half" of the Composer ecosystem - Packagist.

In our last blog post, we saw the basics of Composer but skipped over where it actually finds its packages, and how to publish packages of your own. In this blog post, we will be looking at exactly this, plus some security considerations when using composer in your application.

Packagist is the primary package repository for Composer. This is where you can publish your packages, and also where you can view other people’s packages. Composer will use Packagist to look for packages by default, however, more advanced users can customize this if they wish.

With the basic description out of the way, they then get into how to add your package to Packagist for others to use. The post also talks about package licensing, development versions, branch aliases, security considerations and how to keep on top of new versions of the packages you have installed.

If you've been developing any kind of PHP applications lately, chances are you've at least heard of Composer. This package manager has dramatically changed the way we develop in PHP but there are still some out there wondering what all the fuss is about. In this tutorial from SitePoint author Claudio Ribeiro (re-)introduces this powerful tool and provides some basics of its use.

In this article, we will tackle the basics of Composer, and what makes it such a powerful and useful tool.

Before we go into detail, there are two things that we need to have in mind: what Composer is [and] what Composer is not. [...] Essentially, Composer allows you to declare and manage every dependency of your PHP projects.

He then walks you through the installation of the tool, running it either globally or locally (per-project). He lists out some of the basic commands, what they're for and helps you on your way to installing your first package: PHPUnit. He also covers the special "vendor" folder Composer creates, how autoloading works, various configuration values and installing packages globally rather than just locally. He then talks about the other side of the PHP package ecosystem: Packagist including how to submit packages and set up your own package's composer.json so it can be pulled in correctly.

The Symfony blog has posted an article showing you how to prepare your applications for a migration to PHP 7 with the help of various polyfill libraries. These libraries make it possible to use PHP 7 functionality in non-PHP 7 applications if the function in use isn't defined.

According to the May 2017 PHP Stats, 53% of PHP developers use PHP 7.0 or 7.1, but only 10% of Composer packages require PHP 7.0 or higher. In fact, 1 in 4 packages still require PHP 5.3, which is used by less than 1% of developers.

[...] Upgrading your development machines is usually a simple task, but upgrading the rest of the infrastructure (servers, tools, etc.) usually requires more resources. This is where Symfony Polyfills can help you preparing the code of your application for PHP 7.

The article briefly explains what polyfills are and how to load in the current Symfony set via a Composer install. There've provided functionality for PHP versions 5.4 through 5.6 as well as PHP 7.0 and 7.1 to ensure you have the most up to date functionality at your fingertips.