I love . Laravel As a PHP developer with a history of working in everything from WordPress to CodeIgniter, when Laravel came on the scene it was a revelation. From the design to the usability, it is an absolutely top-notch framework that contains untold depths of power. That said, sometimes Laravel's own opinionated structure can get in the way of what can feel like pretty simple intentions, such as adding custom global arguments to all Artisan commands. What do I mean by "custom global arguments?" As an example, Artisan commands have the all same set of arguments and options that can be used during runtime: --raw             To output raw command list
    --format=FORMAT   The output format (txt, xml, json, or md) [default: "txt"]
    --short           To skip describing commands' arguments
-h, --help            Display help for the given command. When no command is given display help for the list command
-q, --quiet           Do not output any message
-V, --version         Display this application version
    --ansi|--no-ansi  Force (or disable --no-ansi) ANSI output
-n, --no-interaction  Do not ask any interactive question
    --env[=ENV]       The environment the command should run under
-v|vv|vvv, --verbose  Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug But, what if we wanted to add options and arguments? our own A Wild Problem Has Appeared! I've always been a pretty big fan of for both its power and ease-of-use—okay, maybe not so much lately thanks to how poorly they've communicated their most recent , but I've been a fan. Heroku security incident historically One of Heroku's most frustrating drawbacks, though, is how limited the Scheduler is. A kind of half-assed cron, allows you to run any command on 10-minute, 1-hour, or 1-day intervals, which is useful, but also woefully insufficient for many different types of jobs. Heroku's Scheduler kind of What if I only need something run weekly, monthly, or even yearly? Scheduler says "no." So, in order to work around this (within a typical Laravel application), I have traditionally added an additional argument to my Artisan commands that limits running on specific days. For example: php artisan run:command --day=friday Pretty simple design, right? It gets the job done, but it's hardly scalable. Copying the same several lines of " " logic can get pretty tedious (not to mention nothing close to DRY), so I dug into Artisan to better understand how I could add additional global parameters that can be applied to commands, rather than just the ones I specify. if current day == --day parameter, then run, otherwise return 0 all Extending Artisan Thankfully Laravel, being the object-oriented framework that it is, is pretty easy to extend. The challenge isn't so much in the extension as it is in properly writing said extension up into the rest of the application. That said, before we can actually wire up, we first need to extend the class and add our own custom argument. To do this, create a new file called and paste the following code in: anything Console\Application --day ./app/Console/Application.php <?php
namespace App\Console;

use Illuminate\Console\Application as Artisan;
use Illuminate\Support\Str;
use Symfony\Component\Console\Input\InputInterface;
use Symfony\Component\Console\Input\InputOption;
use Symfony\Component\Console\Output\OutputInterface;

class Application extends Artisan
{
    /**
     * Runs the current application.
     *
     * @return int 0 if everything went fine, or an error code
     */
    public function doRun(InputInterface $input, OutputInterface $output)
    {
      if ( !$this->checkDay($input) ) {
        $output->writeln(sprintf('<comment>This command can only be run on %s.</comment>', Str::plural(ucfirst($input->getParameterOption('--day')))), OutputInterface::VERBOSITY_QUIET);

        return 0;
      }

      return parent::doRun($input, $output);
    }

    protected function getDefaultInputDefinition()
    {
        $definition = parent::getDefaultInputDefinition();

        $definition->addOption(new InputOption('--day', null, InputOption::VALUE_OPTIONAL, "Only run the command on the specified day of the week"));

        return $definition;
    }

    public function checkDay(InputInterface $input)
    {
      $day = $input->getParameterOption('--day');

      if ( !$day ) {
        return true;
      }

      return strtolower(now()->englishDayOfWeek) === strtolower($day);
    }
} What the above code is doing can be broken down into a few parts: It creates a new method that gets our custom global parameter ( ) and checks the value against the current day of the week. If the two values are matched (or is not provided), then will return , otherwise it will return . checkDay() --day --day checkDay() true false It extends the method and checks the value of before running the rest of the command. If returns false, the command will immediately and print a comment indicating that the command can only be run on the specified day. doRun() checkDay() checkDay() return 0 Finally, because we want anyone that types to this new argument, we extend and add a new definition indicating that both , and how it works. php artisan --help know about getDefaultInputFunction() --day exists Wiring It Up So, we've extended our console application, but if we were to run our new argument won't show up yet. That's because we need to about our new class, otherwise it will load the original class by default. php artisan --help --day tell Laravel Console\Application To do this, open up and add the following function to the class: ./app/Console/Kernel.php Kernel /**
 * Retrieve the artisan application instance.
 *
 * @return \Illuminate\Console\Application
 */
protected function getArtisan()
{
  if (is_null($this->artisan)) {
    return $this->artisan = (new \App\Console\Application($this->app, $this->events, $this->app->version()))->resolveCommands($this->commands);
  }

  return $this->artisan;
} What the above function does is tell Laravel to load our newly defined class when setting Artisan up, rather than the default class. Because we extended the original class, the existing functionality will still be maintained, but with the new functionality we just added. \App\Console\Application \Illuminate\Console\Application Console\Application Now, if we were to type , we would see a new argument listed in the response: php artisan --help --raw             To output raw command list
    --format=FORMAT   The output format (txt, xml, json, or md) [default: "txt"]
    --short           To skip describing commands' arguments
-h, --help            Display help for the given command. When no command is given display help for the list command
-q, --quiet           Do not output any message
-V, --version         Display this application version
    --ansi|--no-ansi  Force (or disable --no-ansi) ANSI output
-n, --no-interaction  Do not ask any interactive question
    --env[=ENV]       The environment the command should run under
    --day[=DAY]       Only run the command on the specified day of the week
-v|vv|vvv, --verbose  Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug Fin. That's it! All-in-all, it's a pretty straightforward change with some potentially powerful implications. Also published at flower.codes

Heroku

Try these 3 Alternatives to Heroku

You Are Not Worth Tracking, Sorry 

Read My Stories

My Webbed Site

Nominated for 2022 - HackerNoon Contributor of the Year - Website Development

Nominated for 2022 - HackerNoon Contributor of the Year - Privacy

Nominated for 2022 - HackerNoon Contributor of the Year - Internet

Nominated for 2022 - HackerNoon Contributor of the Year - Analytics

Nominated for 2022 - HackerNoon Contributor of the Year - Mental Health

Nominated for 2022 - HackerNoon Contributor of the Year - Productivity

Hire Me

Buy Me a Coffee

Too Long; Didn't Read

Extending Laravel Artisan Commands

Extending Laravel Artisan Commands

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

About Mac Sunsetting macOS Catalina

31 Stories To Learn About Command Line

Developer’s Toolkit: 4 linux command-line tools for debugging everyday issues that all developers…

5 cool things you can do with the Sanity CLI

9 Fun Command-Line Tools to Make Your Life Easier

About Mac Sunsetting macOS Catalina

31 Stories To Learn About Command Line

Developer’s Toolkit: 4 linux command-line tools for debugging everyday issues that all developers…

5 cool things you can do with the Sanity CLI

9 Fun Command-Line Tools to Make Your Life Easier

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps