Package Laravel Package

Getting Started

The package is a base/scaffolding layer ("Package base for CoT Packages") rather than an application-facing feature. You will almost never call it directly from a controller or model — you consume it by extending it when you build your own package in the CupOfTea ecosystem.

Minimal steps:

1. composer require cupoftea/package in the host Laravel app or (more likely) in the package you are authoring.
2. Check composer.json for the extra.laravel.providers / aliases block. If present, Laravel's package discovery registers it automatically; if not, add the provider manually to config/app.php (relevant on older Laravel 5.x installs, which this 2019 release targets).
3. Open src/ and locate the base service provider / base package class. That class is the entry point — read it before anything else, since it defines the conventions (config publishing, migration loading, view namespacing) the rest of the ecosystem expects.
4. Skim the README.md and any stubs/ or config/ directory; the stubs are the fastest way to see the intended developer workflow.

First use case: create your own package's service provider by extending the base provider, so config merging, migration registration, and publish tags come "for free" instead of being re-implemented per package.

// your-package/src/YourPackageServiceProvider.php
use CupOfTea\Package\ServiceProvider; // adjust to the actual namespace in src/

class YourPackageServiceProvider extends ServiceProvider
{
    protected function bootPackage()
    {
        // views, translations, publishes specific to your package
    }
}

Implementation Patterns

Extend, don't wrap. The value of a package base is inheritance of boot/register behaviour. Derive from the base provider and override the hooks (bootPackage, registerPackage, or whatever the class exposes) rather than duplicating mergeConfigFrom, loadMigrationsFrom, and loadViewsFrom calls in every package.

Config-first wiring. Typical base-package shape:

• mergeConfigFrom(__DIR__.'/../config/package.php', 'package') in register()
• $this->publishes([... => config_path('package.php')], 'config') in boot()
• namespace your publish tags (config, assets, migrations) so vendor:publish --tag= stays predictable.

Migrations and factories. If the base loads migrations, keep your package's migrations in database/migrations and rely on the base's loadMigrationsFrom — do not re-register them. For test suites, use orchestra/testbench and let the base provider be the thing under test.

Views / translations / routes. Namespace them (yourpackage::view.name) and register routes behind a config-driven prefix so the host app can toggle the package on or off. Guard optional boot logic with $this->app->runningInConsole() for artisan-only registrations (commands, publish groups).

Version constraint discipline. Because the last release is from January 2019, pin php and illuminate/support constraints explicitly in any package that extends it, and be deliberate about Laravel 5.7/5.8 vs 6+ compatibility. If you need modern Laravel, the base is small enough that forking and updating is usually cheaper than fighting constraints.

Integration tip: treat it as an internal contract. If several CoT packages share the base, upgrading the base is a coordinated change — record the expected base version in each dependent package's composer.json (cupoftea/package: ^x.y) and test the family together.

Gotchas and Tips

• Zero dependents, 0 stars, last release 2019. There is effectively no community signal and no upstream maintenance guarantee. Audit src/ yourself before depending on it, and be prepared to vendor/fork. Do not assume the README reflects current Laravel behaviour.
• Package discovery caching. After adding the provider, run php artisan package:discover (or composer dump-autoload) — stale bootstrap/cache/packages.php is the usual cause of "my provider never boots."
• Publish tag collisions. Generic tags like config from multiple packages overwrite each other silently. Prefer package-prefixed tags, and always vendor:publish --tag=yourpackage-config --force deliberately, never with a bare tag.
• Config caching hides mergeConfigFrom surprises. Test with php artisan config:cache enabled; a base that reads env() at boot will break under cached config.
• Provider order matters. If the base registers bindings your package resolves in boot(), ensure your provider is listed after it — especially when discovery order changes on a fresh install.
• Debugging: php artisan about (newer Laravel) or php artisan tinker + app()->getLoadedProviders() confirms whether the base provider registered; add a temporary dump() in the base's register() if it appears to be a no-op.
• Extension points to check first: any protected properties/methods on the base (config key, view namespace, migration path) are the intended customisation surface — prefer overriding those over re-registering resources yourself, which leads to double-loading.
• Autoload traps. Old packages sometimes ship a files autoload entry or a non-PSR-4 src/ layout; verify with composer dump-autoload -o and check class resolution before blaming Laravel.