Edt Extra Laravel Package

Getting Started

demos-europe/edt-extra is a small companion package (1 star, 0 dependents on Packagist) — treat the source in vendor/ as the documentation, because there is effectively no community footprint to lean on. Before writing any code:

1. Read the manifest first. composer show demos-europe/edt-extra and open its composer.json. Look for a require on a sibling demos-europe/edt* package — "extra" strongly implies it extends a base package, and it will not work without that base installed. Also check the extra.laravel.providers block to get the exact service provider FQCN and any aliases.

2. Install it together with the base:

   composer require demos-europe/edt demos-europe/edt-extra
   

3. Confirm auto-discovery. Laravel's package discovery should register the provider. Verify with php artisan about (Packages section). If it is missing, add the FQCN from step 1 to bootstrap/providers.php (Laravel 11+) or config/app.php (10 and below).

4. Publish anything publishable. There is usually a config file and possibly migrations or views:

   php artisan vendor:publish --provider="DemosEurope\EdtExtra\EdtExtraServiceProvider"
   php artisan migrate
   

   Use the real FQCN from the manifest — do not guess the namespace, it is the most common failure point with low-traffic packages.

5. First use case. Don't try to adopt the whole package at once. Identify the single concrete thing it adds — typically a trait, a model/relation, an artisan command, or a Blade/macro extension bolted onto the base package — and wire that one thing into a throwaway route or tinker session to confirm it resolves from the container.

If after 30 minutes of reading src/ you cannot articulate what it adds over the base package, stop: with 0 dependents and no changelog history, the maintenance cost is likely higher than reimplementing the small piece you need.

Implementation Patterns

Compose, don't fork. The package is designed as a layer over the base edt package. Register it, extend its classes via subclassing or container bindings, and keep your customizations in your own application service provider so you can still receive upstream patches (however infrequent).

Isolate the integration in a domain provider. Rather than scattering references through AppServiceProvider, create something like app/Providers/EdtExtraServiceProvider.php that binds the package's interfaces, publishes config overrides, and registers any macros or custom casts. This makes the dependency easy to audit and easy to remove.

Drive behavior through published config. Override the config file per environment (config/edt-extra.php or whatever it publishes) instead of editing vendor code. Anything the config cannot express should become a binding in your domain provider.

Wrap it behind your own abstraction. Given the low release cadence, put a thin interface in front of the package's primary objects. If the package is abandoned or you later swap it, only the adapter changes:

final class EdtExtraAdapter
{
    public function __construct(private readonly SomePackageClass $inner) {}
    // your app-facing API
}

Test with Testbench or a feature test, not unit mocks. For a package this thin, the value is in its integration with the framework. Use orchestra/testbench if you are wrapping it in a package, or a normal RefreshDatabase feature test in the app. Assert the resolved binding and the one behavior you rely on.

CI hygiene. Pin the version exactly ("demos-europe/edt-extra": "1.x-dev" or the tagged version) and commit composer.lock. With 0 dependents, there is no ecosystem pressure to keep it compatible with new Laravel majors — expect to pin illuminate/* constraints yourself.

Gotchas and Tips

• Bus factor is 1. No dependents, no Stack Overflow answers, no tutorials. Budget time to read vendor/demos-europe/edt-extra/src end-to-end. It is small enough that this is hours, not days — do it before committing to adoption.
• Namespace guessing is the #1 error. DemosEurope\EdtExtra\... is a plausible but unverified guess. Always copy the provider and class names from composer.json and the files themselves. The vendor:publish --provider= command silently does nothing if the FQCN is wrong.
• Framework version constraints. Check illuminate/support and illuminate/database constraints in the manifest. Low-adoption packages often lag by two or three Laravel majors. If you are on Laravel 11/12 and the package targets 8/9, either pin your app back or fork — don't assume it works.
• Auto-discovery can be cached. After composer require, run php artisan package:discover and php artisan config:clear. In production deploys, php artisan optimize after composer install --no-dev is the usual ordering fix for "class not found" on the provider.
• Migrations may collide. If the package ships migrations, check timestamps against your own. Publish, adjust the filename timestamp if needed, and commit the published copy — never rely on vendor/ migrations in production.
• Debugging the resolution. app()->make(TheClass::class) in tinker tells you instantly whether the container binding is wired. If it resolves but behavior differs from expectation, check whether the base package already registers a competing binding — registration order matters, and "extra" packages often need to load after the base.
• Extension points to look for in src/: interfaces you can bind, Macroable traits, config-driven registries, and Laravel events dispatched post-action. These are the only places worth hooking; anything else should be replaced with your own implementation rather than monkey-patched.
• Vendor-fork as an escape hatch. If the package is critical, copy it into packages/edt-extra as a path repository. That converts an unmaintained dependency into code you own and can patch — usually the right call at this adoption level.
• No changelog? Check tags. composer show -a demos-europe/edt-extra lists available versions; if only dev-main exists, treat the API as unstable and isolate accordingly.