Feature Request: Make Solo Project-Agnostic

[ahmedash95]

Hi Aaron,

First off, thanks for the awesome package! I really appreciate the work you’ve put into it.

I’ve got an idea that might make Solo even better. What if it could be project-agnostic? For example, instead of needing to install it for every project, you could just have a .php or maybe a .yml file that we can drop into the project directory. Then, running Solo from there would handle everything.

This would be super helpful in team settings, especially at work where a lot of people are collaborating on the same project. Adding new packages to the shared codebase can be a hassle, and sometimes people push back because they don’t want to use a new tool. A setup like this would avoid those issues and make it much easier for everyone to use.

Just wanted to share this idea. and thanks again for the great tool!

[aarondfrancis]

Interesting idea! I like it in theory but not sure how to execute on it in practice. Stuff like themes, hotkeys, commands, etc all depend on PHP classes, so I feel like a .yml wouldn't work. Maybe a PHP file would, but where would all the supporting stuff go?

[ahmedash95]

I’m glad you liked the idea! Let me elaborate a bit more on what I meant about having a configuration as a .yml file. Here’s an example of what a .solo file could look like:

theme: dark  
commands:  
  auto_start:  
    - name: Logs  
      command: "tail -f -n 100 storage/logs/laravel.log"  
    - name: Vite  
      command: "npm run dev"  
    - name: About  
      command: "php artisan solo:about"  
  lazy:  
    - name: Queue  
      command: "php artisan queue:listen --tries=1"  

With this approach, it becomes really easy to drop a .solo file into any project and configure the commands as needed. As for the theme and PHP class integrations, I’m not entirely sure how those would work in this setup, but I don’t think that should block making Solo project-agnostic.

Additionally, I feel Solo could support both modes: being a package integrated into a project or working as a standalone binary. This would give users more flexibility depending on their workflow and environment.

One more thought: Tinkerwell has a feature where you can write custom drivers in PHP, and it can load and understand them dynamically. Maybe something similar could be used for Solo to make themes and other features configurable too. Here’s a link for reference: https://tinkerwell.app/docs/2/extending-tinkerwell/custom-drivers

[aarondfrancis]

Interesting, I could see it. Maybe project-agnostic Solo is just less powerful (no custom commands, custom themes, etc) and just runs off of a YAML file

[aarondfrancis]

@joshmanders curious your thoughts here

[joshmanders]

I like the idea, would have to figure out what bits are laravel specific and can't just be dependencies of Solo and maybe design a standalone interface that a user could just drop a solo.php into their project that has Solo already in dev dependencies, then they could do something like this

<?php

require_once __DIR__.'/vendor/autoload.php';

\AaronFrancis\Solo\Standalone::run($config);

Then just use it like php solo.php maybe?

[aarondfrancis]

Yeah I don't think I could ever get away from the Laravel dependencies altogether, because it relies very heavily on Symfony's process, but I could make it a standalone thing kinda like Pint is and just read the configuration out of the current project.

[ahmedash95]

Hi Aaron,

I don't think I could ever get away from the Laravel dependencies altogether

Just to clarify, my suggestion isn’t about moving away from Laravel dependencies. I understand how central they are to Solo. My point is that Solo can still rely on the Laravel packages it needs by specifying them in the composer.json under require. For instance, I see you’re already including some Laravel dependencies:

"illuminate/support": "^10|^11",  
"illuminate/console": "^10|^11",  
"illuminate/process": "^10|^11"  

What I’m proposing is the ability to run Solo as a global composer package—similar to expose by Beyond Code.

[ahmedash95]

I like the idea, would have to figure out what bits are laravel specific and can't just be dependencies of Solo and maybe design a standalone interface that a user could just drop a solo.php into their project that has Solo already in dev dependencies, then they could do something like this

<?php

require_once __DIR__.'/vendor/autoload.php';

\AaronFrancis\Solo\Standalone::run($config);

Then just use it like php solo.php maybe?

That sounds great! It would be even cooler if Solo could be installed and run via a global Composer package instead of writing a solo.php file like ☝🏻 .

[Hambrook]

I am also very interested in this.

[joelstein]

My two cents: I came from many years in the Drupal world. So much is now managed in YAML files. It's okay, but one thing I greatly enjoy about the last two years of Laravel development is that everything is PHP. That makes it powerful everywhere. I don't miss fiddling with YAML files.

So whether it's a YAML or JSON file, it's basically just a way to compose what will eventually be PHP. But, more awkwardly.

Whereas, as a PHP file, we have everything at our fingertips to use in the commands.