Skip to main content

Changes to Packages and Configs in Laravel 5

I started a new project late in 2014 which I knew would be fertile ground to keep pace with the what's happening in Laravel 5.  It's been a great learning experience merging in changes from the upstream Laravel project branch as they happened.

The keen observer might have noticed however that Taylor made a commit on December 4th that "broke" support for packages designed to target Laravel 4.

Patience is key, so I was happy to continue waiting for the next great thing.

In Laravel 4, packages allow their configurations to be overridden per environment.  A package can ship a default configuration which can then be copied into the project as a template to be combined with the original's settings at runtime.  Think of it as a really tricked out array_merge_recursive.
By removing ServiceProvider::package, what's being conveyed is that the automatic cascade behaviour is now deprecated.

This might seem distressing, but don't worry.  Any behaviours you've created that might have depended on arrays are still good.  It's just more deliberate - and luckily enough, a great discussion sparked up on twitter yesterday which helped clear a way forward.

(I said it before, but I'll say it again, I really appreciate Taylor's patience as I muddled through understanding the changes.)

I was a bit confused at this point, because I was expecting there to be some kind of magical mechanism between the package and the project still.  Not realizing of course that rather than expecting the two to couple, you simply leverage your project's ServiceProvider to do any customizations.  I had been creating project-level ServiceProviders in my Laravel 4 projects for a while now but more importantly:

This really makes a lot of sense and while I didn't struggle with L4 configs, I'm sure I could see how they came off as a bit arcane to some.  There are a few circumstances where I think people went a bit off the rails with trying to extend or modify the config systems.  Those are their messes to own, but at least now it won't result in them mis-blaming the framework.

Okay, so where does that leave us?  Well, if you're still wondering how you can merge configs and simplify things, there's really just one tweet left in the discussion that helped me understand:

The simplest summary I can offer based on this is that instead of asking Laravel to load and combine configurations, you are now responsible for providing those arrays yourself.  Fear not however, because you can still merge them conveniently using Illuminate\Config\Repository::set.  The reader is encouraged to also look at the utility method array_set and Arr::set.
If you're going to be parsing config for your pacakge, I'd suggest familiarizing yourself with ServiceProvider::register and ServiceProvider::boot.  It's worth noting that boot is optional and supports method-injection from the framework.  This explains why the method isn't present or marked as abstract in the parent.

They're run by the framework in order of register and then boot, so my understanding right now is that you'd do all your config parsing in register and then leverage that configuration in boot or closures.


I'd encourage you not to see these changes as the loss of a feature, but an attempt to help you simplify your projects.  There's been a great push to apply 12factor practices in Laravel 5 - namely configuration and parameterizing your applications. When you decide to dive into using Docker and other hosting setups, you'll be glad these sorts of things happened!

In terms of simplifying resource and configuration file loading - I think Taylor has something in mind.  We simply have to be patient.

Hopefully this post has cleared things up for you.  If I've missed anything or still have it wrong, let me know with a comment!

Popular posts from this blog

Making TypeScript npm Packages

If you've landed here, I can only assume you're like me and see packages as the highest form of sophistication in software development.  In that same vein, I bet at some point in the past you've wished you could start applying DRY principles to your client-side efforts.  I know for myself, I don't enjoy writing the same application bootstrap code constantly and so recently, I was motivated to codify it.

This body of understanding has taken me quite some while to figure out, hopefully what I share here is helpful enough to get you up to speed.  No post is complete without some kind of example, so throughout I'm going to reference a package I've just finished putting together called protoculture.

Briefly described, protoculture encapsulates all the common bootstrap and conventions I've been using while developing TypeScript apps that use React and Redux.  Honestly, I've already gotten a lot of benefit out of putting this package together, but nothing about…

Building .NET Core Nuget Packages

My last blog post was on building and publishing npm packages, specifically for typescript projects. In my opinion, packages are an important fundamental unit in software development. They sit at the confluence of technical competence and collaboration, and represent something the software community should be proud of.
Most of the time, you're going to be creating software packages once you're comfortable with some essential pillars: CodingProject structureSoftware architectureBuildingDeliveryCommunityLicensing
After I got my npm package up and running, my next task was to do the same thing with my C# libraries. Similar to protoculture, I have made a library called praxis.  This is done by leveraging the services and tooling known in the .NET ecosystem as nuget.

In this case, praxis abstracts many of the concepts and functionality I require when producing server projects. It builds on top of ASP.NET Core, so in that sense you can almost think of it as a framework-framework. The…

Laravel Project Architecture: The Missing Guide

At my job, we've been doing a lot of learning and development using Taylor Otwell's Laravel 4 PHP framework.  As we've become more familiar with it, we've had to come up with better ways to structure our projects outside of what the documentation indicates and the default distribution that is provided.

If you've been working with Laravel 4 for any amount of time or come with experience from another framework and are just getting started, you've probably noticed that there are a lot of different ways to cut up your projects.

Choice is nice, but sometimes it can be paralysing or misleading. Concrete Advice This post is done in such a way that you can just skim the headings, but if you want a detailed explanation in each section, feel free to read in where necessary.

While I can't say the entirety of my advice is in practice throughout the community, I can say that we are starting to use it, and to very good effect at my job.  Especially considering that our a…