Google Laravel Package

Getting Started

Before anything else, treat this as a read-the-source-first package: 0 stars and 0 dependents means there is no community trail to follow, but Enso packages are typically small enough to audit in ten minutes.

1. Confirm the shape of the package

   composer show laravel-enso/google
   cat vendor/laravel-enso/google/composer.json   # requires + extra.enso block
   ls vendor/laravel-enso/google/src vendor/laravel-enso/google/config vendor/laravel-enso/google/database 2>/dev/null
   

   The extra.enso block in composer.json is the tell — it usually declares a settings seeder and/or config that Enso's installer wires up.

2. Install into an existing Enso app

   composer require laravel-enso/google
   

   Enso packages are auto-discovered via package:discover, so there is normally no manual providers entry. If the package ships a settings seeder, run it (commonly php artisan db:seed --class=GoogleSettingsSeeder or via Enso's own php artisan enso:init/enso:update flow — check the README and database/ folder).

3. Where to look first

   • src/AppServiceProvider.php (or GoogleServiceProvider.php) — what it publishes, what it binds, and any Settings::set(...) defaults.
   • config/google.php — the canonical list of setting keys.
   • The Settings seeder/migration — the exact keys and default values written to the settings table.

4. First use case — store Google credentials once and read them back anywhere:

   use LaravelEnso\Settings\Facades\Settings;
   
   $clientId     = Settings::get('google.clientId');
   $clientSecret = Settings::get('google.clientSecret');
   $apiKey       = Settings::get('google.apiKey');
   

   (Verify the exact key names — Enso uses both dotted and camelCase conventions across packages.)

Implementation Patterns

Wrap the settings in a single service. Do not scatter Settings::get('google.*') calls through controllers. The package gives you storage; you provide the semantics.

namespace App\Services;

use LaravelEnso\Settings\Facades\Settings;
use Google\Client;

class Google
{
    public function client(array $scopes = []): Client
    {
        return (new Client())
            ->setClientId(Settings::get('google.clientId'))
            ->setClientSecret(Settings::get('google.clientSecret'))
            ->setScopes($scopes ?: []);
    }

    public function apiKey(): string
    {
        return Settings::get('google.apiKey');
    }
}

Treat settings as configuration, not as per-request state. Enso's Settings facade caches values, so read them once at boot/injection time rather than inside loops or queued jobs that may run with a stale cache.

Use Enso's settings UI for operability. The natural day-to-day workflow is: an admin enters the Google client ID/secret in the Enso settings form; your code consumes them. If the package ships a settings page (check src/Http/ or resources/js/), you get that for free. If it only ships the seeder, add the fields to your own settings form and keep the keys the package expects.

Keep per-tenant overrides out of the package. The package stores global values. If you need per-tenant Google credentials, layer your own resolver on top:

public function credentialsFor(Tenant $tenant): array
{
    return $tenant->google_credentials
        ?? ['id' => Settings::get('google.clientId'), 'secret' => Settings::get('google.clientSecret')];
}

Consume in queued jobs and commands carefully. Long-running workers cache the settings bootstrap; if credentials rotate, restart the queue workers. For Artisan commands, resolve the service via the container rather than reading settings at class construction.

Integration tips

• Bind App\Services\Google as a singleton so the Google\Client (and its token state) is reused within a request.
• Prefer injecting the wrapper over the Settings facade in anything you intend to test — you can then fake the wrapper instead of touching the DB.
• If the package only advertises "helpers", check whether those helpers are just thin Settings::get shims; if so, replacing them with your own wrapper is zero-risk.

Gotchas and Tips

Settings caching will bite you. Enso caches the settings table. After updating Google credentials (via UI, seeder, or tinker), run php artisan cache:clear (or the Enso-specific settings cache clear) before testing. A surprising fraction of "my credentials don't work" bugs are stale cache.

Secrets live in the database in plaintext unless the package says otherwise. Enso's settings table is JSON, not encrypted by default. If this package doesn't cast the secret to encrypted, consider storing only the client ID there and keeping the secret in .env, or wrapping the read/write yourself. Audit the Settings model/casts before you put production OAuth secrets in it.

Version-pin aggressively. With zero dependents, nobody else is exercising the compatibility matrix against new Enso/Laravel releases. Pin laravel-enso/google and laravel-enso/settings together in composer.json, and test upgrades of Enso core in a branch.

Verify what "helpers" actually means before relying on them. The package name promises settings and helpers, but the helpers may be a handful of static methods that just read three keys. Skim src/ — if there's no HTTP client, no token refresh, and no caching of Google responses, you're still responsible for the actual Google API call, retry logic, and token lifecycle. This package is a config store, not a Google SDK.

Check the service-provider ordering against laravel-enso/settings. Enso packages that seed settings assume the settings table exists. On a fresh install, run Enso's base migrations first, then this package's seeder — otherwise you'll get a "table not found" during db:seed.

Publishing and overriding. If the provider offers --tag=google-config (or similar), publish it and commit the published file so your key names are stable across upgrades. Don't edit anything in vendor/.

Extension points to look for (in order of usefulness):

• A publishable config file — the cleanest way to change default keys.
• A bound service or interface — swap the implementation in your own provider.
• Events fired on settings change — useful if you need to invalidate downstream caches (e.g., a cached Google access token).

Debugging checklist when a value comes back null:

php artisan tinker
>>> DB::table('settings')->where('key', 'like', 'google%')->get();
>>> \LaravelEnso\Settings\Facades\Settings::get('google.clientId');

If the DB has it but Settings::get doesn't, it's caching or a key-name mismatch (dotted vs camelCase). If the DB is empty, the seeder didn't run.

Bottom line: adopt this only if you're already inside an Enso app and want Google credentials to follow the same settings pattern as everything else. Outside Enso, config/services.php plus .env is simpler and better supported.