Laravel Agent Cost Laravel Package

Getting Started

v1.0.1 adds an opt-in prebuilt dashboard, which changes the recommended first-run path: you no longer need to build a UI before you can see the package working.

1. Install and publish the config (tag name may differ slightly — check php artisan vendor:publish output):

   composer require <vendor>/<package>:^1.0.1
   php artisan vendor:publish --provider="<Vendor>\<Package>\<Package>ServiceProvider"
   

2. Open config/<package>.php first — this is the source of truth for the release. Look for the dashboard block added in 1.0.1 and flip it on:

   'dashboard' => [
       'enabled' => env('<PACKAGE>_DASHBOARD_ENABLED', false),
       // likely: 'path', 'middleware', 'domain'
   ],
   

3. Clear cached config, then confirm the routes actually registered:

   php artisan config:clear
   php artisan route:list | grep -i dashboard
   

4. First use case: enable it in local/staging only, hit the dashboard route, and use it as a read-only sanity check that your data/queue/integrations are wired correctly before writing any custom code.

The dashboard is deliberately off by default. Treat "enable it and look" as step one of onboarding, not as a production feature decision.

Implementation Patterns

Environment-scoped enablement. Drive the flag from env rather than hardcoding true. Enable in local and staging, keep it off in production until you've reviewed what it exposes:

// config/<package>.php
'enabled' => env('<PACKAGE>_DASHBOARD_ENABLED', app()->environment(['local', 'staging'])),

Protect it before you ship it. The prebuilt dashboard is a convenience, not an authorization model. Wrap it in your own middleware/gate in the config rather than trusting the default:

'middleware' => ['web', 'auth', 'can:viewAdminPanel'],

If the package exposes a Gate/policy hook, register it in a service provider so the check is testable rather than buried in config.

Use it as a scaffold, then diverge. The fastest path is: enable the dashboard, screenshot what you need, then publish the views (usually --tag=views) and move the parts you care about into your own app. Don't fork the vendor views in place — publish, then edit, so upgrades stay clean.

Pair with the programmatic API. The dashboard is a view over whatever the package exposes. For anything you'll automate (alerts, reports, tests), call the underlying API/service directly and keep the dashboard for humans. This keeps your business logic independent of a UI that's one minor version old.

CI and test guardrails. Add a test asserting the dashboard route is absent (or 403s) under your production-like config, so a stray APP_ENV or copy-pasted .env doesn't expose it:

public function test_dashboard_is_not_reachable_for_guests(): void
{
    $this->get('/<dashboard-path>')->assertRedirect('/login');
}

Onboarding lever. Because it's config-only, new team members can see real data on day one without writing a line of code. Document the two-step enable in your README — this is the single highest-value thing v1.0.1 gives you.

Gotchas and Tips

• Config cache is the #1 failure mode. Toggling enabled in .env does nothing after config:cache. Always php artisan config:clear locally and confirm your deploy pipeline re-runs config:cache after the env is in place.
• Routes may only register when enabled. If the dashboard 404s, that's likely the intended behaviour, not a bug. Check route:list before debugging middleware.
• Don't assume the default middleware is enough. Prebuilt dashboards frequently ship with web only. Verify against a logged-out session and a low-privilege user before enabling anywhere shared.
• Path collisions. If the default path is generic (e.g. /dashboard) and you already own that route, set a custom path or domain in config rather than renaming your own route.
• Asset/build step. Prebuilt UIs often need published assets or a compiled bundle. If the page renders unstyled, look for an assets publish tag or a documented build command before assuming the config is wrong.
• Stale published views after upgrade. Once you publish and edit views, a future release's dashboard improvements won't reach you. Note the version you published at, and diff on upgrade.
• Extension points to lean on first: config file → published views → custom widgets/panels → service container bindings. Work left-to-right; most needs are satisfied by config or views alone.
• Version pin. Use ^1.0.1 and read the changelog for 1.0.x patch releases — a dashboard landing in a patch version suggests the maintainers are shipping fast, so pin deliberately.