Composer now supports PSR-4

Posted: 2014-01-03
Category: PHP

I haven't really posted about PSR-4 here other than as a footnote in this old article, but if you follow me on Twitter or hang out on Reddit you've probably seen some news about it.

PSR-4 was voted in as an "accepted" PSR by the FIG in December. It took a little while to get done and went through a series of painful rewrites but when we have in the end is a document that reflects what this truly is: an improvement on PSR-0.

Today Jordi Boggiano merged a pull request by Andreas Hennings into master branch of Composer that contained support for PSR-4. Andreas was a massive help to the FIG while we were trying to shake the issues out of PSR-4 during Draft and Review stages, so he really outdone himself by providing the code too.

Jordi wrote a blog about why you don't want to switch all of your packages immediately to PSR-4 as many users won't be reminded to update for another 30 days, so for now I am suggesting people create a feature branch called "feature/psr4" for those who want to try it out, to get their packages and unit-tests ready for February 4th 2014 - when it will be "PSR-4 Upgrade Day".

Converting is easy as hell. Take a look at Fractal feature/psr4 to see how to do it yourself.

The Composer Autoload documentation is already updated for PSR-4 too.

Please post up here in the comments or on Twitter if you upgrade your package(s) to PSR-4. I'd love to make a list of early adopters on here, and maybe make it into another article in a few weeks.


Hari Kt


Some people in @auraphp was blaming for no autoloader support for PSR-4. So the first PSR-4 class loader has been released

And all the version 2 packages are using PSR-4 . And the early days of Aura version 1 was really supporting PSR-4 though ;) .

Amy Stephen


Congratulations and thanks, very much, for your efforts on this. I thought maybe it would never be passed but in the end, a good PSR and one that should wear well over time.



I am sorry to ask you here, but the post about "The Tribal Framework Mindset" has been closed.
I wonder about your words:
> If you are building a PHP package then you are faced with two options:
> 2. Make it run with every framework out there

The idea is superb but I wonder how does this go with the reality?
The major thing that using a framework gives us is the standards. But folloving those standards we are obliged to do things in the choosen framework ideology way.
Sorry I am not familiar with Laravel which you seem to prefer. Maybe there is some way to write an agnostic code which would both work for this framework and could be used from outside.
But in what way?:
1) some functionality that I create should be implemented like some independed classes (with no dependence from framework classes). And to create a chosen framework component one would need to use in it's new component this independent classes
2) or maybe you mean situation when in my project I want to use some functionality from some framework and I set up this framework in my "require" composer.json section, so I would have all this framework as one of my vendors and use (if possible) some functionality from it and it's extensions.

For a variant 1) I wonder how it could be done for example with Yii 2 (Yii framework is popular in our countries, so we learn it) . If I need to create some model (which could be any functionality because it is the M part from MVC ideology) I am supposed to create my specific model on top of basic \yii\base\Model class. So if I write some , for example, poll builder it would be only yii specific solutuin. And if I am forced to develop using another framework it won't be of much help. Maybe only variant 2 then, but I did not give it a try, whether there are some actual obstacles to use it like that.



Mikhail: For Laravel (or similarly for Silex) you simply add a service provider, which will sit on top of generic code but provide a nice way to integrate config and create an instance. The code beneath it is completely generic.

Take a look at this article:

Your framework agnostic package would not have models in. Instead it would simply define some interfaces for those models and define the methods your models should have.

Other developers then have the choice of either just implementing those models in their own application, or maybe somebody can do that for them in a "yii-whatever" package, which requires your "whatever" package. This is known as a "bridge" package.

Chris Duell


FYI the "Fractal feature/psr4" link is now dead.

Phil Sturgeon


Chris: Yeah dude I merged it. :)

Chris Duell


would make sense to update the link then, no?

Posting comments after three months has been disabled.