Rob Allen has a post to his site for the OpenWhisk (a serverless cloud platform) users out there that want to use Composer to install dependencies required by your application.

When creating new OpenWhisk actions in PHP, It's likely that you'll want to take advantage of the rich ecosystem of Composer packages on Packagist.org.

The OpenWhisk PHP runtime has you covered with some pre-installed Composer packages and also the ability to upload your own using a zip file.

He starts by mentioning the two packages that come installed by default: Guzzle and the ramsey/uuid library. He then gets into the upload of your own project files as a ZIP file and how to install the package locally, bundle it up into this archive and push it using the wsk command line tool.

On his site Colin O'Dell has a new post about a major milestone one of the packages he supports has crossed - the 1 million download mark. His post doesn't talk about how amazing the package, league/commonmark, is or even what it has to offer but about the process of getting there and the community support that made it possible.

This morning I came into work to find my Packagist download counter had rolled over: league/commonmark now has over 1,000,000 downloads!

To celebrate this milestone I thought I'd share the story of how this package came about, how it's grown, and how I couldn't have reached this milestone without the PHP community's help.

He talks about the initial creation of the package, its early days and how it was invited to become a part of the PHP League group of packages. He talks about improvements made to the package since then, including some integrations with other tools and projects. He then ends the post with thanks to the community for the support and their efforts to help make this package and all of them that make up the PHP ecosystem possible.

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 BugSnag blog has posted a tutorial from a guest author, Graham Campbell, introducing you to Packagist and the PHP ecosystem continuing on from the previous post introducing the Composer tool.

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.

The post starts off by introducing Packagist and how you can distribute your package there. There's a section that covers Open Source licenses, a few of the different types and how to list licenses of your currently installed packages. Following this the post talks about using branches and aliases to pull in the code you need (not just the latest release). The tutorial wraps up with a look at some of the security concerns around using packages and how to keep on top of new versions with new bugfixes.

In a new post to his site Jordi Boggiano, lead developer on Composer and Packagist.org, talks about typo-squatting and Packagist, a trend that has come up in other communities but - so far - not as much in the PHP ecosystem.

Earlier this month an article was published summarizing Nikolai Philipp Tschacher's thesis about typosquatting. In short typosquatting is a way to attack users of a package manager by registering a package with a name similar to a popular package, hoping that someone will accidentally typo the name and end up installing your version of it that contains malware.

The thesis mentions https://packagist.org as a good example as we use vendor namespaces. [...] Despite this mitigating fact, it is still technically possible to squat the vendor name, so I wanted to take a look at our repository data and see if I could spot any bad actors.

He wrote a script on the current contents of the Packagist site to see if he could find any packages that were trying to take advantage of typosquatting. He describes what the script does and the results: a low number of issues where it mostly seemed to be user error, not malicious behavior.

Jordi Boggiano has posted some updated statistics around the use of the Packagist site around PHP version requirements and the relation of package downloads to PHP versions.

Last year I posted stats about PHP versions, and the year before as well, both time in November. However this year I can't wait for November as I am curious to explore the PHP7 uptake!

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 28 days 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 compares the previous statistics against the ones gathered back in November 2015, both in numbers and graphs. He shows the stats for the PHP versions being used and for the PHP versions that are required. It's interesting to see that there's been a good uptick in supported versions including PHP 7.0+.

In a post to his site Freek Van der Herten shows you how to gather information from the Packagist website about the number of times that your packages have been downloaded.

At my work I’m currently creating a new dashboard. That’s a fancy term for an html page sprinkled with some Vue magic that will be displayed on tv screen at the wall of our office. I won’t say much about the dashboard itself on this post, but I’ll make sure to write something on that in the near future.

One of the things I want to display on our dashboard is how many times our packages get downloaded (yeah it’s a vanity project, sorry about that :-)). To make this real easy our intern Jolita and I cooked up a new package called packagist-api. It uses the packagist api to fetch data about published packages.

They include an example of the package in use, fetching the list of packages for the "spatie" vendor and getting the details by package name. The results include more information than just the download count as well (including current version, maintainers and the basic description). The post ends with an example of filtering out the downloads counts and putting them into a collection for later use.

Jordi Boggiano has a new post to his site today sharing some interesting PHP package statistics he gathered as a part of the metadata in the Composer/Packagist ecosystem.

This one started in a peculiar way. Paul M. Jones announced a new version of his Producer tool, I had a look at it and saw that it recommended having a changelog called CHANGES.md by default. [...] My first thought was to report an issue asking to change the default, but then I thought it's Paul, he will not just take my word for it, he will want hard facts. So here I am two days later. I queried GitHub's API for the file listing (only the root directory) of all PHP packages listed on packagist.org. What this let me do is look at what files are commonly present (and not), which is quite interesting to get a picture of the whole ecosystem.

He queried about 79,000 packages and found some interesting patterns in the results. These included findings like:

• 8% have a DependencyInjection/ directory, which I believe indicates Symfony bundles
• 3.6% have a examples/ and 3.5% a docs/ directory
• 49% have some file or directory indicating the presence of tests (phpunit.xml & co)
• 14% have committed their composer.lock
• 8% show a presence of some code quality/style CI (scrutinizer, codeclimate, styleci)

There's some other interesting statistics in the post around license files, changelogs and CLI binaries too. He's also posted the full data set for anyone interested in running some of their own statistics on the results.

It's come to "that time of year" again and Jordi Boggiano has posted the latest update in his series of PHP usage statistics. In this summary he looks at the PHP versions installed based on the packagist.org logs for developers using Composer.

It's that time of the year again, where I figure it's time to update my yearly data on PHP version usage. Last year's post showed 5.5 as the main winner and 5.3 declining rapidly. Let's see what 2015 brought.

[...] A quick note on methodology, because all these stats are imperfect as they just sample some subset of the PHP user base. [...] 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. Of course this data set is probably biased towards development machines and CI servers and as such it should also be taken with a grain of salt.

He first compares the statics for his 2015 searches against the 2014 stats and shows the differences in usage for PHP versions 5.3.3 up to 5.6.0. Fortunately, the results show a rise in the usage of PHP 5.5 and a decline in all others...but it's not too much of a difference (2-3% range). Pie graphs are also included to help visualize these differences. He also includes some statistics on what PHP versions are required by certain packages for the ones listed on Packagist with increases starting with 5.4 and the largest advance for 5.5.