GitHub adds PHP and Composer dependency graphs

Here are some great news from GitHub: Dependency graph support is now available for PHP repositories with Composer dependencies.

You may see security alerts on your repositories as dependency graph support rolls out. When there’s a published vulnerability on any of the Composer dependencies that your project lists in composer.json and composer.lock files, GitHub will send you an alert including email or web notifications, depending on your preferences.

These now work for both public and private repositories, and repository admins can enable or disable the features as needed.

Semantic Versioning – why you should care

Semantic Versioning – why you should care” is a nice take on Semantic Versioning and how and why people should is. I particularly liked the practical examples of changes and which version bump they correspond to.

I frequently find myself explaining the Semantic Versioning to developers, and going over some example changes. Now I can just send the link to that article instead and safe myself some time.

Very nicely done!

PHP : Composer Galaxy

PHP has one of the greatest, in my opinion, dependency managers – Composer. The tool works mostly with the public projects via the Packagist website (although it also supports private repositories).

There are over 200,000 packages available on the Packagist to choose from. However, the stats could be a lot better.

Today I came across a mind-blowing visualization of the composer packages and the dependencies between them. Have a look at Code Galaxies Visualization. You can find specific packages via the search, or interactively navigate the star map, like you are in the spaceship.

Stunning!

Our Software Dependency Problem

Our Software Dependency Problem” is a great article going in-depth into the subject of the dependency management during software engineering.

Dependency managers have scaled this open-source code reuse model down: now, developers can share code at the granularity of individual functions of tens of lines. This is a major technical accomplishment. There are myriad available packages, and writing code can involve such a large number of them, but the commercial, legal, and reputational support mechanisms for trusting the code have not carried over. We are trusting more code with less justification for doing so.

Not only it nicely describes the problem in simple terms, but also provides practical examples and solutions to it. In particular, I enjoyed the section that suggests how to improve dependency evaluation in terms of design, code quality, testing, debugging, maintenance, usage, security, and licensing.

Show outdated composer packages


A while back I shared a way to show outdated composer packages.  Today, I want to expand on it a little bit.  Thanks to this tweet:

I think it’s slightly easy to remember with “composer show -molD -strict” (“old”, “mold”).  Adding this to the test suite is a great tip too!

For other ways to show the outdated packages (using composer plugins), have a look at this StackOverflow thread.