Tomas Votruba has a new post to his site showing you how to add a global option or argument to your application that makes use of the Symfony Console component. In this case, a "global" option is one that can be given to any command in the application. For his needs, it's a filename.

I'm working on 3 Console Commands. All was good, until I needed to add an argument to all commands at once... and in lazy, extensible, maintainable way.

He starts by talking about some of the "why" behind the need to run multiple commands at once. He shows an example of having multiple CHANGELOG files and the need to define the output file for each rather than just one file. He then goes through four different possible implementations, including the code and pros/cons of the approach:

• Add Argument to Each Command
• Modify Application Definition
• The Symfony Event Subscriber Way
• Extend the Application

He ends the post mentioning the one he prefers (the last one on the list) and briefly mentions anti-patterns and finding the right solution over just the first one you find.

Tomas Votruba has continued his series covering the use of the Symfony Console component with a new tutorial. In this latest article he shows how to get "stylish and standard console output" using the output formatting included with the package.

Even if you don't use any component from Symfony or even installed one, you can use this trick in your PHP CLI App.

It's simple, provides standard and makes your output look like a design from Apple - useful and nice at the same time.

He starts by introducing the OutputInterface that the Symfony Console package includes and shows a few screenshots of the difference between normal console output and the Console component's look. He also covers the SymfonyStyle functionality that allows for even more fine-grained control over the input and output handling of your application. He finishes the post showing a few tips on integrating these styles into your command line application and setting it up to fetch SymfonyStyle as a service.

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.

On his site Tomas Votruba continues his look at the Symfony/Console component of the Symfony framework. In this latest article he walks through the loading of configuration options from a file provided by a --config option on the command line.

PHP CLI apps usually accept config, to setup their behavior. For PHPUnit it's phpunit.xml, for PHP CS Fixer it's .php_cs, for EasyCodingStandard it's easy-coding-standard.yml, for PHPStan it's phpstan.neon and so on.

In the first post about PHP CLI Apps I wrote about poor DI support in PHP CLI projects.

Today we look on the first barrier that leads most people to prefer static over DI - how to load config with services.

He starts off talking about the "chicken and egg" issue when it comes to loading configuration: needing a configuration to create an Application instance which then needs the config (and so on...). He then walks through three possible solutions:

1. Not using a container to manage dependencies for the application
2. Setting up a container in a command
3. Using the ArgvInput input helper to pull directly from the arguments

He gets into more detail on this last method, providing code examples and input/output examples of it in use. Unfortunately this method also introduces some undesired dependencies between commands. He finishes the post with an alternative: setting up option definitions in the getDefaultInputDefinition method of the main application and having them available to all commands.

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.

The Yappa.be blog has a tutorial posted sharing the method they used to implement queued and scheduled execution of Symfony commands. This is made possible by the Enqueue package.

At Yappa, we have always used Johannes' JMSJobQueueBundle to run and schedule Symfony console commands for background jobs.

However, we've stumbled upon a much more elegant solution called Enqueue. [...] It's packed with features, supports major brokers such as RabbitMQ, Kafka, Amazon SQS, Google PubSub, Redis etc. and has a bundle ready to be used with Symfony.

[...] One downside is that the Enqueue Symfony bundle doesn't provide an out of the box solution to queue Symfony console commands and there's no 100% straight forward way to implement this. In this post I'll cover the basics in setting up the Enqueue Symfony bundle so we can easily queue Symfony console commands!

The tutorial then walks you through the installation of the Symfony bundle, adding it to the list of installed bundles and configuring it with basic parameters and queue connection details. Next they've included the code to create the processor used when a command is pushed to the queue. To handle the other side (execution of the command when the queue is handled) they create a "QueuedCommand" value object and a command handler class. With this structure in place they show the addition of test commands to the queue and the result when the queue is consumed.

On his Medium.com site Agustín Houlgrave has posted a tutorial with some suggestions about building PHP console applications correctly.

Googling this topic, I could only find official documentation on Symfony’s Console Component and some tutorials on quick building, but i’d like to write about making a real scalable console application that you could use in an actual production project. I’ll explain the reasons we do each of the things.

I like to write decoupled, reusable and as raw as possible code, so we’ll try to aim on that direction. Also, we’ll take advantage of all of the new features of PHP 7.

He decided on the combination of the Symfony Console Component and the Zend Service Manager to handle the use of the decoupled components. He then gets into the installation of the required packages and the initial code to create the Symfony command. He then sets up the Composer autoloading and the "factory" configuration for the command. From there he includes the code to build out the command runner and gives an example of executing the command and the output.

The SitePoint PHP Blog has a new tutorial posted from author Claudio Ribeiro that takes you beyond the basics with the Symfony Console component, showing you how to use some of the helpers and other tools included in its functionality.

It’s undeniable how useful console commands can be when developing software. Not too long ago we re-introduced the Symfony Console component.

This component allows us to create structured and testable CLI commands. We created some simple commands and tested them; but when our commands become bigger and more complex, we need a different set of tools.

This is what we are going to look at today: advanced Symfony console tools.

He then walks you through the installation of the component via Composer and the initial creation of a "FizzBuzz" console command class (and other related classes). He then shows how to use several of the helpers:

• the "question" helper to ask for user input
• the "table" helper for outputting structured data
• the "progress bar" helper to visually output progress of a task

There's also examples included showing how to call a command from inside a command and changing up color and style of the output.

On the Laravel News site they've posted a tutorial showing you how to create custom Artisan commands making them available right along with the built-in framework commands.

I’ve written console commands in many different languages, including Node.js, Golang, PHP, and straight up bash. In my experience, the Symfony console component is one of the best-built console libraries in existence—in any language.

Laravel’s artisan command line interface (CLI) extends Symfony’s Console component, with some added conveniences and shortcuts. Follow along if you want to learn how to create some kick-butt custom commands for your Laravel applications.

The tutorial starts off with an overview of the current command structure and how a basic Symfony Console command is structured (code). They then get into the creation of their custom command - a "health check" command - by creating a new Laravel project and using the "make:command" command to build out the skeleton code for you. They add the command into the current config and show output of how it should now show in the "help" listing. From there the tutorial shows how to implement the HTTP checking with Goutte and how ot run it on a schedule, writing the result of the check to a log.

The SitePoint PHP blog has posted a tutorial from author Claudio Ribeiro that wants to re-introduce you to the Symfony Console package, a component of the larger Symfony framework that makes it easier to create and work with command-line PHP scripts.

As software developers, we often feel the need to resort to command line tools. These kinds of tools are helpful when we need to do a sort of recurring task like migrating data, performing imports, or creating cron jobs.

The Symfony Console component tool provides us with a simple framework to create our own command line tools. Unlike many components in Symfony, this is a standalone package and is used by the likes of Laravel‘s Artisan and many other famous PHP packages.

The tutorial then walks you through the installation process, via Composer, and the creation of a new command. With this simple base created, he then adds in actual functionality, building out a command to hash and verify a password string. They show how to use the command and an example of its output. Next up, he creates another command example, this time verifying the password hash provided as an argument. The tutorial wraps up with a look at testing your console comamnds with PHPUnit tests via the included CommandTester functionality.