Marcel Pociot has written up a post to finish out 2017 and provide a year in review for the community and language via some Github statistics.

It's this time of the year again - the end of the year is coming up fast, so why not step back and take a look at what we, as a PHP community, have achieved this year?

For these statistics, I used the free GitHub Archive data in combination with Google BigQuery, which lets you process 1TB of data per month free of charge.

So let's take a look at some numbers

He first breaks it up into three main categories:

• most starred PHP repositories
• most starred new PHP repositories
• most contributed PHP repositories

From there he "digs deeper" and looks at the packages requiring the most dependencies and graphs the frameworks according to how many dependencies they require to install.

Christopher Pitt has posted the second part of his series about creating "Dependable", a Laravel-based application with a focus on Composer use and customization. In part one he laid the foundation, creating a new project, database and setting up migrations to create the tables. In part two he builds on this and creates additional functionality to store a GitHub user's repositories.

One of the ideas we’ve had is to create an application; which can build a custom Composer dependency map, and deploy that to a new server. It would also be great if there was an interface for deciding which dependencies are included, and a unique URL for each installation.

He starts with a brief mention of testing and why he hasn't included that in his current work. Then he gets into the new models for storing repositories and the migration to create the matching table. He also includes the code that will be needed to link a Developer to a Repository. He finishes the post with an endpoint that can be called to refresh the data from GitHub and pull the repository information down and populate it into the database.

Matthew Weier O'Phinney has a recent post about recent work that's been done to split up the componenents in Zend Framework 2 into their own repositories and linked as dependencies.

Today we accomplished one of the major goals towards Zend Framework 3: splitting the various components into their own repositories. This proved to be a huge challenge, due to the amount of history in our repository (the git repository has history going back to 2009, around the time ZF 1.8 was released!), and the goals we had for what component repositories should look like. This is the story of how we made it happen.

Matthew talks about the methods that were used to split things apart, even more so than they already were. While the components could be installed separately before, the methods used to get there were "cringeworthy". He talks about the different methods they've tried and the version bump issue that came with them, even when no changes were present. He talks about the ultimate goal of the refactor and the techniques to get there - a combination of grafts, subtree, subdirectory-filter and tree-filter through git. He covers some of the "stumbling blocks" they hit along the way including empty merge commits. The end result was a one-line command that could be executed and split out the provided component (well, with a lot of help behind the scenes).

He ends the post talking about the speed of the extraction process (hint: parallel processing is a happy thing), the ultimate results of the entire framework being split and a few lessons they learned along the way.