On the Laravel News site they've posted a tutorial showing you how to create multi-stage Docker builds for Laravel applications with a feature included in Docker 17.05.

Starting in Docker version 17.05 multi-stage builds are available to help you optimize Dockerfiles. Using multi-stage builds is a clean way to set up a Docker build pipeline that simplifies the requirements you need on your CI/build server to create a Docker image for your app.

If you’re not familiar with multi-stage builds, no worries! Let me summarize by saying that before multi-stage builds if you wanted to install composer dependencies and frontend dependencies during a docker build of your app, your Docker image would need to have the necessary dependencies such as Node.js installed and Composer PHP.

[...] By using multi-stage builds, you no longer need to install those dependencies or cram them all into your Dockerfile, thus bloating your final image size!

The tutorial then walks you through the multi-stage build approach using a new "demo" Laravel application as the base. In their example they show how to create the application, add it to a Git repository and set up the environment configurations. Next it includes the Dockerfiles required to create the different stages: installing Composer dependencies, installing Node dependencies and copying the application files and artifacts in to place.

In a quick post to the Laravel News site they mention another new feature coming in the v5.7 release of the framework: the addition of the dump server for debugging output.

At Laracon US 2018 Taylor Otwell announced that Laravel Dump Server would come packaged with Laravel in version 5.7! It will be a development dependency in laravel/laravel composer file.

Starting in Laravel 5.7 you’ll get this command out-of-the-box that allows you to dump data to the console or an HTML file instead of to the browser.

The post outlines what the "dump server" provides and provides an example of the command used to start it up. You can find out more about the dump server in this previous article.

On the TutsPlus.com site today they've posted a tutorial sharing some examples of dependency injection using the Symfony DependencyInjection component.

In this article, we'll look at some examples of using the Symfony DependencyInjection component. You'll learn the basics of dependency injection, which allows cleaner and more modular code, and you'll see how to use it in your PHP application with the Symfony component.

The tutorial starts by introducing the component and what kind of functionality it includes to help register and fetch services on demand. It then walks through the installation (via Composer) and the installation of other optional related packages. It then dives into the code, showing how to put the package to use to register a new service and pull it back out to use. The article then moves on and shows a more "real world" example with services that have dependencies and configuring it in a YAML configuration file.

Matt Sparks has posted the next tutorial in his "Building a PHP framework" series to his site today. In this latest article (part seven in the series) he focuses on building the container to handle dependencies.

Part 6 began our discussion of PHP containers. Today, I’ll be going into greater detail of the subject and, along with that, I’ll run down the work done so far on the Analyze container.

A huge debt of gratitude goes how to the folks behind the PHP League Container and others. I’ve learned a ton studying their code.

He then walks through the use of the container he created, Analyze/Container, to create and extract a Carbon instance. He then covers how the container is working behind the scenes to initialize the instance complete with dependencies (and optional arguments).

Rob Allen has continued his series of posts covering the use of PHP on the OpenWhisk platform. In his latest tutorial he shows how to use dependency injection for use in "non-trivial PHP applications".

Any non-trivial PHP applications use various components to do its work, from PDO though to classes from Packagist. It’s fairly common in a standard PHP application to use Dependency Injection to configure and load these classes when necessary. How do we do this in a serverless environment such as OpenWhisk?

This question comes up because we do not have a single entry point into our application, instead we have one entry point per action. If we’re using Serverless to write an API, then we probably

He uses a common connection type - PDO to a database - to illustrate a method for injecting dependencies in a serverless application. In his example, he starts with a simple script that returns a set of "todo" items from the database (with the PDO connection code embedded in it). Using dependency injection is a better way to manage that PDO connection so he shows how to update it to use the Pimple DI container and inject it via the constructor to make it available to the rest of the application.

Tomas Vortuba has continued his series looking at building command line tools with PHP and the Symfony Console component. In this latest post he shows how to create an application using dependency injection in just four files.

Series about PHP CLI Apps continues with 3rd part about writing Symfony Console Application with Dependency Injection in the first place. Not last, not second, but the first. Luckily, is easy to start using it.

He starts with a bit of information about how Symfony has evolved from the previous method of using controllers as services to create CLI tools. Now commands can be used as services and be pushed into/pulled from a dependency injection container. He then walks through the three steps to adding a command as a service:

1. updating the services.yml file to include linking for the console application class.
2. updating the Kernel to load the yml configuration.
3. creating the bin file to execute the application.

With this structure in place, he then shows how to share functionality between services using a CompilerPass.

In a new post to his site, Tomas Votruba has a post sharing his thoughts about why you should combine Symfony Console and dependency injection and how it can help tp resolve issues with the overuse of static methods and functions.

I saw 2 links to SymfonyConsole in today's Week of Symfony (what a time reference, huh?). There are plenty of such posts out there, even in Pehapkari community blog: Best Practice for Symfony Console in Nette or Symfony Console from the Scratch. But nobody seems to write about the greatest bottleneck of Console applications - static cancer. Why is that?

He starts with some examples of the current status in PHP console applications including PHP_CodeSniffer, PHP CS Fixer and PHPStan. Each of these load commands to add functionality to the application which, as the application grows and changes, could be difficult to maintain in the future. Instead he recommends making use of dependency injection. He then talks about how containers are already a part of the console applications mentioned and finishes up focusing on the combination of the SymfonyConsole and SymfonyDependencyInjection components.

Tomas Votruba has a new post to his site showing how to "turn your Symfony project to legacy" through the use of action injection for mapping controllers and methods to request handling.

The other day I saw the question on Reddit about Symfony's controller action dependency injection. More people around me are hyped about this new feature in Symfony 3.3 that allows to autowire services via action argument typehints. It's new, it's cool and no one has a bad experience with it. The ideal candidate for any code you write today.

Since Nette and Laravel introduced a similar feature in 2014, there are empirical data that we learn from.

Today I'll share the experience I have from consulting few Nette applications with dangerous overuse of this pattern and how this one thing turned the code to complete mess.

He starts off with some example code, asking where the issue is showing a call to a service handler to process the an argument. This would be used when a controller is registered as a service to help reduce the amount of work to define routes and add more "magic" for request handling. While the idea sounds good, he points out some of the issues with the approach including dependency injection problems and how, if it expands outside of controllers, it can lead to a poorly written application.

In a previous post to his site Andrew Embler provided a "concrete guide to dependency injection", a method to help make code easier to test and more flexible/maintainable. In this latest post he continues the series and moves to the next topic: dependency injection containers.

I recently posted about dependency injection, a guide that I hope was easy to read and understand. It's a topic that's confusing, due in no small part to its name. As I mention there, the same term defines the simple process of externally providing instance variables to a class as it does to the Container object's magical auto-instantiation of object (which also "injects dependencies.")

I'd like to talk a bit more about that. Now that we understand the term "Dependency Injection" (which is simply providing classes to classes through a constructor or a setter), let's talk about how we might make this a little less onerous.

He starts with an example from the concrete5 project where a class would require three object instances each time it would be created. Fortunately the software includes a make command that does some of this work for you. It makes use of a dependency injection container behind the scenes to get the instances it needs. He then covers cascading dependencies, some special logic for class creation and how to "get fancy with it" by defining custom logic when an instance is created.

Frank de Jonge has a new post to his site covering something that always seems to be a difficult topic in development: time. In his post he suggests that date and time handling in your application is a "dependency" that could be difficult test.

When developers talk about the infrastructural boundaries or external dependencies they often talk about databases and third-party integration. They're the first thing we'll put behind an interface so we can stub them out during our tests. This gives us some control over them. It's become relatively easy to spot these dependencies because we do it frequently. They're the usual suspects.

However, some "dependencies" are much harder to spot. They even live right inside the standard library of PHP and often manage to seep through the cracks. Date/Time handling is such a thing. So what's the problem and how do we fix it?

He goes on to talk about date/time handling programming languages in general and how its variance can can cause issues that might be out of our control. He suggests that when time "gets the best of you" you should opt to be more specific in your date/time handling (the cause is usually precision). He then gets into some code examples of how to "control time" by reducing the impact that direct date/time handling could have on your application. He also includes an example of testing this handling and finishes with the idea of "consuming time as a service".