Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: allow non-standard namespace for SoloServiceProvider #14

Merged

Conversation

eleftrik
Copy link
Contributor

If your SoloServiceProvider is stored in a namespace which is not the standard App\Providers, Laravel Solo is gonna "complain" because commands are being registered from an unsafe location.

This PR adds the method useCustomNamespaceProvider, which tells Laravel Solo to consider it as a safe location to register commands from.

This method takes the service provider instance itself as an argument of AaronFrancis\Solo\Providers\SoloApplicationServiceProvider type (which your service provider is subclass of): this ensures that the user is not trying to register as safe an arbitrary class namespace.

Example:

namespace App\Custom\Namespace\Providers;

use AaronFrancis\Solo\Commands\EnhancedTailCommand;
use AaronFrancis\Solo\Facades\Solo;
use AaronFrancis\Solo\Providers\SoloApplicationServiceProvider;

class SoloServiceProvider extends SoloApplicationServiceProvider
{
    public function register()
    {
        Solo::useTheme('dark')
            // Call before registering commands!
            ->useCustomNamespaceProvider($this)
            // Commands that auto start.
            ->addCommands([
                EnhancedTailCommand::make('Logs', 'tail -f -n 100 ' . storage_path('logs/laravel.log')),
                'Vite' => 'npm run dev',
                // 'HTTP' => 'php artisan serve',
                'About' => 'php artisan solo:about'
            ])
            // Not auto-started
            ->addLazyCommands([
                'Queue' => 'php artisan queue:listen --tries=1',
                // 'Reverb' => 'php artisan reverb:start',
                // 'Pint' => 'pint --ansi',
            ])
            // FQCNs of trusted classes that can add commands.
            ->allowCommandsAddedFrom([
                //
            ]);
    }

    public function boot()
    {
        //
    }
}

@aarondfrancis
Copy link
Owner

This seems like a good solution. Where do you normally store your service providers if not App\Providers?

@eleftrik
Copy link
Contributor Author

@aarondfrancis I use a domain-driven oriented folder structure inspired by Spatie's "Laravel beyond CRUD", at least for medium-sized applications.

In short: src/App/Support/Providers/SoloServiceProvider.php.

@aarondfrancis
Copy link
Owner

@eleftrik do you still have an App\Providers\AppServiceProvider in this setup?

@aarondfrancis
Copy link
Owner

@eleftrik I changed it up a bit! Let me know what you think

@aarondfrancis aarondfrancis merged commit 4e0c49b into aarondfrancis:main Nov 20, 2024
8 checks passed
@eleftrik
Copy link
Contributor Author

Hi @aarondfrancis, sorry for the late reply. I totally missed notification emails from GitHub.

do you still have an App\Providers\AppServiceProvider in this setup?

No.

I'll take a look at your code as soon as I can. Thanks for considering this PR and improving the code!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants