Capitalize "app" in namespace in settings classes generated with Artisan console

[jlswanson28694]

When generating settings classes with the make:setting Artisan command, the namespace of the class defaults to app\Settings instead of App\Settings like all other files generated through Artisan commands. This isn't usually a problem, but it led to some confusion when it comes to caching the settings class.

Assuming it would be capitalized, I wrote a helper function that loads my main site settings class using app(App\Settings\SiteSettings::class). This returns the class just fine, but since the namespace of the settings class was defined as app\Settings, the values of the settings class were cached with the key settings.app\Settings\SiteSettings. I am using Redis for caching, where the keys are case sensitive, so it ends up looking for settings.App\Settings\SiteSettings in the cache and can't find anything.

[rubenvanassche]

Isn't this solved with this PR: #190?

[jlswanson28694]

That PR is definitely discussing the same issue, but I'm looking at the commit, and it doesn't actually solve anything.

Line 113 in MakeSettingCommand.php:
$namespace = str_replace('/', '\\', trim(str_replace(ucfirst(base_path()), '', $path), '/')) . ';';

Looking at this line of code, app\Settings will not be capitalized because ucfirst is only capitalizing base_path(). I'm using Laravel Sail, and base_path() returns /var/www/html, so ucfirst() is trying to capitalize a forward slash.

ucfirst() should be wrapped around the trim() function, or around the whole $namespace variable assignment.

[rubenvanassche]

You're always welcome sending in a PR fixing this!

[edrisaturay]

Still not solved.. and still getting
namespace \app\Settings;

Hopefully soon and thanks guys for the great set of Libraries.

[rubenvanassche]

Cannot reproduce on newest version:

a make:setting SomeSettings

<?php

namespace App\Settings;

use Spatie\LaravelSettings\Settings;

class SomeSettings extends Settings
{

    public static function group(): string
    {
        return 'default';
    }
}

Looks fine to me, we had a lot of PR's recently to the commands so maybe someone fixed it. Otherwise you're still free to send in a PR fixing this issue.

[jlswanson28694]

I made PR #200 specifically to fix this, so yes it is resolved ;)