East Common Laravel Package

Product Decisions This Supports

• Build-vs-buy input for foundational components — this package bundles user management, persistence, templating, and filesystem adapters in one place. A PM evaluating whether to assemble these in-house versus adopt a framework bundle can use it as a reference point for scope, but the answer it points toward is almost always “use the mainstream framework primitives,” not “adopt this.”
• Architecture reference for domain/infrastructure separation — the src/ vs infrastructures/ split (Symfony, Doctrine, Flysystem, minify adapters) is a clean illustration of how to keep domain logic framework-agnostic. Useful as a design blueprint for teams planning a modular monolith or a future framework migration, independent of whether the code itself is adopted.
• Roadmap deprioritization data point — 2 stars, 0 dependents, and a single-maintainer pattern are strong signals against putting this on a delivery roadmap or in a dependency manifest. It informs “don’t build a feature on top of this” more than “build this feature.”
• Ecosystem-fit check — it clarifies whether the team is actually in the #East/Teknoo ecosystem. If not, this package resolves nothing that Laravel or Symfony does not already solve natively.
• Not a feature-enabler. No product feature should be gated on adoption; the value is architectural literacy, not shipped capability.

When to Consider This Package

Consider it only if:

• The team has already committed to the #East programming philosophy and the surrounding Teknoo stack (East-Foundation, Recipe); this package is a complement to that ecosystem, not a standalone entry point.
• You are on Symfony + Doctrine MongoDB ODM, not Laravel. Despite the framing, this is a Symfony-oriented library with PHP-DI/Symfony DI, MongoDB ODM persistence, Twig components, and Symfony UX — there is no Laravel service provider, no Eloquent, no Blade integration.
• You can run PHP 8.4+ in production today. That requirement alone excludes a large share of managed hosting and many enterprise runtime baselines.
• You want a worked example of decoupled architecture for internal study, not a production dependency.

Look elsewhere when:

• You are on Laravel — use the framework’s native auth (Breeze/Jetstream/Fortify), Eloquent, Blade, and Filesystem. This package offers no Laravel integration and would require bridging work that erases any savings.
• You are on Symfony — use Symfony Security, Doctrine ORM/ODM, Twig, and Flysystem directly. You get the same primitives with orders of magnitude more adoption, documentation, and security review.
• You need maintenance assurance. With 2 stars, 0 dependents, and BSD-3-Clause with a single-vendor provenance, there is no community bus factor. A production bet here is a bet on one maintainer’s continued interest.
• You need PHP 8.2/8.3 compatibility, standard LTS support, or vendor security SLAs.

How to Pitch It (Stakeholders)

For executives: This is a small, low-adoption open-source PHP library — two GitHub stars, no downstream dependents — that bundles common web-application building blocks (users, persistence, templating, storage). It is not a platform decision and should not appear on the roadmap. The one thing worth extracting is its architecture pattern, which keeps business logic cleanly separated from framework code; we can borrow that idea at zero cost and zero dependency risk. Recommendation: do not adopt as a dependency; treat as a design reference only.

For engineering: It’s a Symfony-first library following the #East philosophy, requiring PHP 8.4+, PHP-DI, Doctrine MongoDB ODM, and Flysystem. There is no Laravel integration, so for our stack it would mean writing the bridge ourselves. The genuinely valuable artifact is the src/ (domain) versus infrastructures/ (adapters) separation — a good model for keeping our core logic portable across frameworks and testable without a container. Everything it provides, our framework already provides with vastly better support and security coverage.

Risk summary: Adoption risk is high (single-maintainer, near-zero adoption, bleeding-edge PHP floor), integration cost is non-trivial for non-Symfony stacks, and the upside is architectural rather than functional. Read the source, cite the pattern, skip the dependency.