aedart/athenaeum
Aedart Athenaeum is a collection of reusable PHP and Laravel utility components—helpers, service providers, traits, and data structures—you can pull into any project. Install only what you need, or use the full suite as a foundation for your own applications.
Start with a single component, not the mono package. aedart/athenaeum is a metapackage that pulls in dozens of independent aedart/* components. In a Laravel app most of them (container, configuration, events, HTTP) overlap with what the framework already gives you. Install only what you need:
# For a Laravel app — pick individually
composer require aedart/type-safe aedart/properties aedart/design-patterns
# For standalone package/CLI development
composer require aedart/athenaeum
Where to look first. The repo is a mono repository: each component lives under its own directory with its own README.md, composer.json, and CHANGELOG.md. The root README is the index — read it to find the component you actually want, then jump straight into that component's folder. Namespaces are Aedart\<Component>\..., not Athenaeum\...; the repo name is only the umbrella.
The first use case worth trying is the type-safe / property components, because they solve something Laravel does not: enforcing types and validating values on plain PHP objects (DTOs, value objects, config objects) without dragging in a full validation layer.
use Aedart\Properties\Traits\Properties;
class Money
{
use Properties;
protected int $amount = 0;
protected string $currency = 'EUR';
public function getAmount(): int { return $this->amount; }
public function setAmount(int $value): void { $this->amount = $value; }
}
The trait routes __get/__set (and getProperty() / setProperty() / hasProperty()) through your real getters and setters, so you get magic access and enforced types at the same time.
For Laravel package authors, look at aedart/laravel-bootstrap and aedart/laravel-service-provider next — they provide conventions for registering config, migrations, translations, and routes from a package, which is boilerplate you would otherwise hand-roll.
Properties traits for DTOs and settings objects. Use Properties on non-Eloquent classes only. It is a clean way to build immutable-ish value objects, config objects, and request payloads where you want getters/setters with type enforcement but still want $obj->name to work in views and tests. Pair with aedart/type-safe for coercion and validation at the boundary.
Overload trait for trait method collisions. When two traits both define boot() or handle(), the Overload component lets you disambiguate at call time instead of writing aliases for every method:
use Aedart\Overload\Traits\Overload;
$this->overload()->handle($payload); // resolves per trait-name convention
This is the one component that is genuinely hard to replace with vanilla PHP, and it is most useful in base classes and reusable traits you share across projects.
Design patterns as small, composable traits. aedart/design-patterns gives you FactoryMethod, Proxy, Singleton, and friends as traits rather than full frameworks. The Proxy pattern is handy for lazy resolution of expensive services — wrap the real service and let the proxy resolve it on first method call. In Laravel you already have the container and Illuminate\Support\Facades\Facade, so use these only when you need a proxy inside a domain object that must stay framework-agnostic.
IO helpers for testing streams. aedart/io gives you stream and file abstractions that let you build an in-memory stream from a string. This is useful when you need to test code that accepts a PSR-7 body, a CSV import, or a file download without touching the filesystem:
$stream = Streams::fromString('id,name' . PHP_EOL . '1,Alice');
Laravel integration via a binder service provider. Register Athenaeum-backed services in a dedicated provider rather than scattering new calls. Use the framework's container for lifecycle; use Athenaeum's aedart/container only in non-Laravel CLI/standalone code. Keep a one-way dependency: Laravel app code may use Athenaeum, but Athenaeum objects should not reach back into app() or facades — that is what keeps them testable.
Package-level conventions. If you are publishing your own package, aedart/laravel-bootstrap gives you a provider with hooks for config publishing, migration loading, and route registration. Model your composer.json extra.laravel.providers entry on it, and your package will behave like the rest of the ecosystem.
Validation layers. aedart/validation is standalone and rule-based. Use it for domain validation that must run outside HTTP (queue jobs, console commands, imports). Don't duplicate it with Laravel's Validator in the same flow — pick one and be consistent per layer.
aedart/* package versions independently; the meta-package only pins a compatible set. Always read the README for the version you installed — the API and PHP requirement (8.0 vs 8.1 vs 8.2) can differ between components.Properties on Eloquent models. It defines __get/__set behaviour that will fight Eloquent's attribute and relationship magic. Same for Overload on models — __call collisions with query builder forwarding are painful to debug.Overload resolution is convention-based. Method dispatch depends on the trait name + method name pattern. If a call falls through to __call unexpectedly, dump the trait list with class_uses() and confirm the naming matches what the component expects. __call dispatch also has a small performance cost — avoid it on hot paths.composer show aedart/* and inspect each composer.json for extra.laravel.providers; otherwise you will register providers by hand and wonder why nothing is bound.main will show you unreleased APIs.Aedart\Contracts\... interfaces (e.g. property, type, stream contracts). Implement the contract and bind it in your provider rather than subclassing — the concrete traits assume the interface, not a specific class.composer.json, keep an eye on CHANGELOG.md for breaking changes across major bumps, and budget time to fork if a component is abandoned mid-project.How can I help you explore Laravel packages today?