Dashed Core Laravel Package

Getting Started

Because this package has no dependents and no published documentation beyond the README, treat the first hour as an audit rather than a tutorial. Establish what you actually installed before writing a line of application code.

1. Install and pin.

composer require dashed/dashed-core --prefer-dist
composer show dashed/dashed-core

Note the exact version. With zero dependents there is no ecosystem pressure to keep the API stable, so pin to an exact tag ("dashed/dashed-core": "1.0.0", not ^1.0) and commit composer.lock.

2. Verify the release metadata. The registry reports a last release date of 2026-06-19, which is a future-dated tag. Confirm whether that is a dev- branch alias, a mis-tagged commit, or a genuinely scheduled release:

composer show dashed/dashed-core --all | head -40
git -C vendor/dashed/dashed-core log -1 --format='%H %ci %s'

If the tag points at a commit that is not on the default branch, assume it is untested.

3. Find the service provider and what it registers.

grep -A5 '"extra"' vendor/dashed/dashed-core/composer.json
ls vendor/dashed/dashed-core/src

Laravel's auto-discovery will have registered the provider already (check php artisan about --only=drivers or bootstrap/cache/packages.php). Read the provider's register() and boot() methods in full — that is the real documentation for a package like this. Specifically look for:

• mergeConfigFrom() → the config key you can publish
• loadMigrationsFrom() → whether migrations are auto-loaded or must be published
• loadRoutesFrom() → whether routes are registered for you or opt-in
• $this->app->bind() / singleton() calls → the contracts you should be injecting instead of concrete classes

4. Publish and migrate.

php artisan vendor:publish --tag=dashed-core-config
php artisan vendor:publish --tag=dashed-core-migrations
php artisan migrate

If a publish tag does not exist, --provider="Dashed\Core\DashedCoreServiceProvider" will list everything available; run it without --force first to see the manifest.

5. Read the contracts before the models. Look under src/Contracts (or src/Repositories, src/Support — naming varies in packages this small). Those interfaces are the seam you will be allowed to override later. Any class implementing one of them is a candidate for container rebinding in AppServiceProvider.

First use case: wire the package's content repository into a single read-only controller and render one record. Do not start with the admin UI or with writes. A read path proves config, migrations, and container bindings are all live; anything more ambitious will mix those three failure modes together.

// routes/web.php
use Dashed\Core\Contracts\ContentRepository; // confirm namespace in src/Contracts

Route::get('/preview/{slug}', function (string $slug, ContentRepository $content) {
    return view('preview', ['entry' => $content->findBySlug($slug)]);
});

If the binding resolves and the query returns a row, the install is sound. Everything after that is application design.

Implementation Patterns

Inject the interface, never the implementation. Packages at this maturity level rename concrete classes between patch releases. The interface is the contract the package itself depends on, so it survives longer. Type-hint it in constructors and let the container resolve it.

Override bindings after the package provider registers. Package providers are booted from bootstrap/providers.php (Laravel 11+) or config/app.php before your AppServiceProvider. That ordering is what makes rebinding work:

// AppServiceProvider::register()
$this->app->singleton(
    \Dashed\Core\Contracts\ContentRepository::class,
    \App\Cms\DatabaseContentRepository::class
);

Never edit files in vendor/. If you need a behaviour change, decorate:

final class CachedContentRepository implements ContentRepository
{
    public function __construct(private ContentRepository $inner) {}

    public function findBySlug(string $slug): ?Content
    {
        return Cache::remember("cms:{$slug}", 3600, fn () => $this->inner->findBySlug($slug));
    }
}

Wrap the package's routes rather than replacing them. If the provider registers a route group, you usually get the least friction by keeping it and attaching your own middleware through the config file, instead of duplicating controllers:

// config/dashed-core.php
'route_middleware' => ['web', 'throttle:60,1'],
'route_prefix'     => 'cms',
'register_routes'  => env('DASHED_ROUTES', true),

That register_routes flag is worth inventing if it does not exist — most CMS cores let you disable front-end routing so your routes/web.php remains the single source of truth for public URLs.

Treat content writes as events, and cache invalidation as a listener. A CMS core that caches reads will need invalidation on publish. If the package dispatches domain events, subscribe to them; if it does not, wrap the write path in your own service so you have a place to hang Cache::forget:

// EventServiceProvider
Event::listen(\Dashed\Core\Events\ContentPublished::class, function ($event) {
    Cache::forget("cms:{$event->content->slug}");
    Cache::tags(['cms'])->flush(); // only with a tag-capable store
});

Constrain the model surface in your app, not in the package. Expose your own Eloquent models or DTOs to controllers and keep the package's models behind a mapping layer. When the package changes a column or a relationship name, you repoint one mapper instead of grepping your codebase.

Test against a real migrated database. Use RefreshDatabase and seed through the package's factories if they ship; otherwise build fixtures that go through the repository's public write methods so they exercise the same path production does. Avoid mocking the repository in feature tests — the binding is exactly what you are trying to verify.

Multi-environment config. Set the config file's values from .env rather than editing the published file per environment, so php artisan config:cache produces the same artefact everywhere.

Gotchas and Tips

Zero dependents means zero field reports. No one has hit the edge cases before you. Budget for reading source on every upgrade, and keep the diff surface small by pinning. If the package turns out to be load-bearing, fork it into a private VCS repo and treat that fork as your dependency.

Verify the future-dated release before trusting it. A 2026-06-19 tag is either a typo, a dev-master alias, or a mis-set commit date. composer show --all and git log will tell you. If the tag is not an ancestor of the default branch, install from the branch instead and pin the commit SHA:

"dashed/dashed-core": "dev-main#a1b2c3d"

Migrations: published vs. loaded. If the provider calls loadMigrationsFrom(), do not also publish the migrations — you will get duplicate-table errors. Conversely, if you publish them and later upgrade, php artisan migrate will not pick up new package migrations because your copy shadows them. Decide once: publish (you own the schema, upgrades are manual) or load (the package owns the schema, your local edits are lost). For a package with no upgrade history, publishing is the safer choice.

Config cache staleness. After php artisan config:cache, edits to config/dashed-core.php have no effect until config:clear. This is the single most common "the package is broken" false alarm. Add php artisan optimize:clear to your deploy script's failure runbook.

Route caching and closures. If you define CMS routes with closures (as in the Getting Started snippet), php artisan route:cache will fail in production. Convert to invokable controllers before your first deploy.

N+1 on polymorphic content relations. CMS cores typically attach fields, blocks, or media polymorphically. A listing page will fire one query per row. Eager-load aggressively and verify with DB::listen or Telescope rather than assuming:

$entries = $content->paginate(20)->with(['fields', 'media', 'author']);

Container resolution order is the debugging lever. If your override is not taking effect, php artisan tinker and resolve the interface — you will see which concrete class won. If it is the package's, your provider registered too early or you bound the concrete class rather than the interface.

Reserved config keys and facade aliases. Check config/app.php aliases and the published config for names that collide with your app's (e.g. a Content facade alias). Aliasing conflicts produce confusing "class not found" errors that point at your own code.

Extension points to look for, in priority order: (1) container bindings to interfaces, (2) config-driven middleware and route flags, (3) domain events for cache invalidation and side effects, (4) Macroable traits on the core service classes, (5) published views you can override by namespace (view('dashed-core::...')). If the package offers none of these, that absence — not any specific bug — is the reason to wrap it in your own thin service layer rather than calling it from controllers directly.

Debugging checklist when something silently does nothing: provider present in bootstrap/cache/packages.php → config actually published and not cached → migrations ran (php artisan migrate:status) → binding resolves to your class in tinker → routes appear in php artisan route:list. Work that list in order; it isolates the five failure modes this class of package actually has.