teknoo/east-common
teknoo/east-common provides shared utilities, interfaces, and base classes for Teknoo East PHP applications, helping standardize configuration, dependency injection, and common infrastructure across components.
Architecture fit. The package is architected around a clean domain/infrastructure split (src/ vs. infrastructures/) that maps to hex-ish / ports-and-adapters patterns — a solid design principle in isolation. However, the design is heavily opinionated around the #East programming philosophy and depends on Teknoo/East-Foundation and Teknoo/Recipe. For a TPM evaluating against a typical Laravel/PHP product, this is not a modular library you can partially adopt — it is a full-stack architectural commitment. Fit is therefore high only if the team is explicitly buying into the Teknoo ecosystem; otherwise it is misaligned with framework-idiomatic Laravel/Symfony application patterns.
Integration feasibility. Infeasible as a drop-in for a Laravel project. The exposed infrastructure adapters are Symfony bundles, Doctrine MongoDB ODM, Flysystem, Matthiasmullie Minify, and Symfony UX — Symfony-centric and MongoDB-centric. Laravel teams would need to author custom adapters (Eloquent persistence, Blade/Twig rendering, Illuminate DI instead of PHP-DI/Symfony DI). Combined with the PHP 8.4+ minimum, integration is a bespoke engineering project, not a composer require. Flysystem integration is the only genuinely framework-agnostic surface.
Technical risk. High. Signals: 2 stars, 0 dependents, bus-factor of 1 (TeknooSoftware), no visible commercial support, and a bleeding-edge PHP floor that will not meet most production runtime policies today. The transitive coupling to East-Foundation/Recipe means breaking changes upstream propagate here. Security posture depends entirely on the maintainer's response cadence. BSD-3-Clause itself is permissive and fine; the risk is continuity, not licensing.
Key questions. (1) Is there internal appetite or existing expertise in the #East philosophy, PHP-DI, and Doctrine MongoDB ODM? (2) Does our platform actually run MongoDB in production, or would we be introducing a new datastore purely for this package? (3) Will our runtime support PHP 8.4+ within a reasonable horizon? (4) What is the upstream release cadence and issue response SLA on Teknoo/East-Common, East-Foundation, and East-Recipe? (5) If the maintainer disappears tomorrow, who owns patches — is an internal fork acceptable? (6) Is there any documented reference application using this stack at scale?
Stack fit. Poor-to-moderate against a Laravel baseline; good against a Teknoo/Symfony stack that has already committed to East-Foundation. The src/ domain layer is reusable in principle, but every material integration surface (DI container, persistence, templating, asset pipeline) is Symfony/Doctrine-shaped. Realistic fit requires either (a) adopting the broader Teknoo/Symfony stack wholesale, or (b) building and owning Laravel adapter shims.
Migration path. Not a lift-and-shift. Recommended path: (i) treat the package as a greenfield / bounded-context option, not a refactor of an existing app; (ii) begin with a timeboxed spike proving one capability (e.g., object persistence via a custom Laravel repo) in isolation; (iii) only proceed if the spike validates effort estimates. A retro-migration of an existing Laravel codebase to this stack is likely to exceed the cost of building equivalent internal components.
Compatibility. Validate against PHP 8.4+ runtime policy first — this is a hard gate. Confirm mongodb PHP extension and MongoDB server availability. Symfony bundles imply Symfony 6/7 alignment and Symfony UX stack; Flysystem and Minify have softer constraints. Because dependents = 0, expect to be the first to exercise real-world combinations — compatibility discovery cost is on you.
Sequencing.
make depend / test / qa per the documented Makefile to confirm the repo is buildable as-shipped.Maintenance. Effectively single-vendor. With 0 dependents and 2 stars, our team would become one of the very few production consumers and bear disproportionate maintenance weight. Budget for internal ownership of upstream patches, security reviews, and PHP-version catch-up work. A standing internal fork is not a hypothetical — plan for it.
Support. No evidence of commercial support, SLAs, or a broad contributor base. Documentation is AI/dev-facing (AGENTS.md style) rather than user-facing, which raises onboarding and incident-resolution time. Support requests will be GitHub-issue based with uncertain latency.
Scaling. Horizontal scaling is architecturally plausible: MongoDB ODM fits sharded/partitioned persistence; Flysystem abstracts object storage; Symfony DI is compile-cached for runtime. Costs are in operational complexity of running MongoDB alongside the rest of the stack, and in the Symfony UX / Twig render path — usually minor but worth load-testing early. No first-party benchmarks are provided, so scaling assumptions must be validated internally.
Failure modes. (1) Upstream abandonment — the most probable long-tail failure; dependency rot and unpatched CVEs. (2) Breaking changes in East-Foundation/Recipe propagating into this package. (3) PHP version drift — being pinned to 8.4+ means lagging security updates during runtime transitions. (4) Doctrine MongoDB ODM incompatibility with newer PHPs or MongoDB server versions. (5) Talent risk — the skill pool for #East/PHP-DI/Doctrine-ODM is small; key-person unavailability stalls delivery. (6) Silent behavioral drift — Behat/universal test coverage is good for authors but does not substitute for consumer integration testing.
Ramp-up. High. Engineers must absorb: #East philosophy, PHP-DI/Symfony DI, Doctrine MongoDB ODM, Flysystem, Symfony UX, and the Makefile-driven QA workflow (PHPStan, PHPCS, PHPUnit, Behat). Realistic ramp-up for a mid-level PHP engineer is multi-week before productive contribution, and longer before they can confidently patch upstream. Factor explicit training and pairing time into the delivery plan, and ensure at least two engineers own the stack to mitigate the bus-factor risk.
How can I help you explore Laravel packages today?