Core Laravel Package

Getting Started

Step 1 — Confirm the package identity and pin it. The repo is redot-src/core, but the Composer name is redot/core. Confirm the vendor on Packagist before requiring, then pin an exact version — with 1 star and 0 dependents, you do not want ^ drift on an unmaintained upstream:

composer show redot/core --all   # verify vendor, versions, deps
composer require "redot/core:x.y.z"

Step 2 — Resolve the license before writing any application code. The metadata says NOASSERTION, which is not permission. Read the actual LICENSE file in the repo and get an internal sign-off. If it stays ambiguous, stop here — everything below assumes the license permits internal commercial use.

Step 3 — Verify auto-discovery instead of assuming it. Laravel registers the provider through extra.laravel.providers:

php artisan package:discover
php artisan about              # confirm a Redot/Core entry appears

If discovery fails, copy the provider FQCN from the package's composer.json into config/app.php manually.

Step 4 — Publish selectively, then migrate. List publish tags first so you know what you're about to own:

php artisan vendor:publish --provider="Redot\Core\CoreServiceProvider" --list
php artisan vendor:publish --provider="Redot\Core\CoreServiceProvider" --tag=config
php artisan migrate

First use case — one vertical slice. Boot the default dashboard route (commonly /dashboard or /admin) behind your own auth middleware, then add a single custom widget or page through the package's registry. That one slice exercises install, discovery, config, views, routing, and the extension API — the fastest way to map where the seams are before you build ten screens on top of them.

Where to look, in this order:

1. composer.json — sub-package dependencies plus the provider FQCN. This tells you what "core" actually wraps.
2. config/ — the published config is usually the registry of widgets, pages, and menu items; it's your real API surface.
3. src/ — service provider register()/boot(), plus any helper files in autoload.files (globals that load on every request).
4. routes/ and resources/views/ — routes the package owns, and the layout you will extend.

Implementation Patterns

Compose through your own provider, not AppServiceProvider. Create a dedicated DashboardServiceProvider that does every Redot registration — widgets, pages, menu entries, config overrides. One auditable, deletable file if you ever rip the package out.

Register extensions through the registry, never in vendor/. Widgets and pages go into the published config array or a register() call. Vendor edits vanish on composer update and are invisible in code review.

// app/Providers/DashboardServiceProvider.php
public function boot(): void
{
    config(['redot.widgets' => array_merge(
        config('redot.widgets', []),
        [\App\Dashboard\Widgets\RevenueWidget::class],
    )]);
}

Wrap helpers behind one app-level adapter. Helper functions and global classes are convenient but create coupling across the whole codebase. Route every call through a single class:

namespace App\Support;

class Dashboard
{
    public static function registerWidget(string $class): void { /* redot call */ }
    public static function menu(): array { /* redot call */ }
}

A future swap or removal then touches one file instead of fifty call sites.

Override views outside vendor/. Publish views, then @extends the dashboard layout from your own pages. To replace a single Blade component, use view()->prependNamespace() or drop a same-named file in your published views directory.

Align auth and middleware deliberately. Wrap dashboard routes in your own auth/verified/can: stack and confirm which guard the package assumes. If it expects web and your app uses a custom guard, test login redirects, session persistence, and logout end-to-end before building on it.

Extend at the sub-package level when you need a fix. Because core aggregates sub-packages, require the specific sub-package directly and constrain it yourself. Fork core only for genuine core bugs, and vendor it via a VCS repository entry:

"repositories": [{"type": "vcs", "url": "[email protected]:yourorg/redot-core.git"}]

Daily loop: build → register → smoke-test. For every widget or page, add a feature test asserting the route returns 200 for an authorized user and that expected data appears in the response. That test suite is your only upgrade safety net — there is no upstream CI you can lean on.

Gotchas and Tips

• NOASSERTION is a stop sign, not a "we'll figure it out." Missing license metadata is not a permissive grant. Legal sign-off gates every line of code here.
• Zero dependents means zero ecosystem safety net. No community patches, no Stack Overflow answers, no release cadence guarantee. Budget for a fork and internal ownership from day one, and commit composer.lock.
• Meta-package version conflicts are the most likely install failure. Core's sub-package constraints can collide with what your app already requires. Read every constraint in composer.json before requiring; if it fails, resolve conflicts by pinning sub-packages directly rather than loosening your own constraints.
• Audit autoload.files for global helpers. Files loaded via autoload.files execute on every request, including queue workers and console commands. Grep for side-effecting code there — it's a common hidden performance and correctness trap.
• Watch for hidden coupling. The package likely assumes Redot-specific auth models, database schema, frontend build tooling, or route names. Any of these can collide silently with an existing app; check migration ordering and route names before your first migrate.
• Migration and asset collisions. If the package ships migrations, confirm table names don't clash with yours. If it ships assets, verify they publish and build under your Vite/Mix setup — missing asset pipelines are a frequent "dashboard renders blank" cause.
• Debugging discovery and boot order. If routes 404 or config is empty, run php artisan package:discover -v and check your DashboardServiceProvider is registered after the package provider. A dd(config('redot')) in a tinker session tells you instantly whether config published correctly.
• php artisan about is your fastest health check. If the Redot/Core entry is absent, nothing downstream will work — fix discovery before debugging anything else.
• Benchmark against Filament before committing further. If "Filament does this and is maintained" is the honest answer after the spike, take Filament and cite this package only as a design input. Keep the evaluation timeboxed to roughly half a day of source reading.