Core Laravel Package

Technical Evaluation

Architecture fit. erdiko/core is not a Laravel package — it is the core of the Erdiko micro-framework, a standalone Slim-derived MVC stack with its own container, routing, config, and view layers. It has no service provider, no facades, no Laravel contracts, and no PSR-11/PSR-15 alignment that would let it slot into Laravel's kernel. Architecturally it is a competing framework kernel, not a composable library, so the fit with a Laravel application is poor by construction. The only realistic value is as a reference implementation for concepts (module bootstrapping, lightweight DI, config layering), not as a runtime dependency.

Integration feasibility. Low. Installing it alongside Laravel will almost certainly produce Composer conflicts: the last release is April 2017, which predates Laravel 5.5+ package auto-discovery and targets PHP 5.6/7.0-era constraints. Modern Laravel (8/9/10/11) requires PHP 7.3+/8.1+, and the transitive dependency graph (Slim 2/3-era components, older PSR packages) will collide with Laravel's own contracts and Symfony versions. Cherry-picking individual classes is theoretically possible but pulls in framework-wide assumptions (global container access, Erdiko-specific config paths), making extraction costlier than rewriting the equivalent in Laravel primitives.

Technical risk. High.

• Abandonment: repository is archived and the last release is over seven years old; there is no upstream security response path.
• Security exposure: unpatched transitive dependencies are the primary concern — installing this is effectively importing 2017-era CVEs into the dependency tree.
• Runtime incompatibility: likely fatal errors or deprecation warnings on PHP 8.x; no typed properties, no modern error handling.
• Lock-in: any code written against Erdiko idioms is not portable to Laravel and vice versa.
• Reputation signal: 18 stars and a 0.21 score indicate negligible community validation; there is no ecosystem to lean on for fixes.

Key questions for the TPM to resolve before any decision.

1. What is the actual underlying need — a specific utility (config loader, router, view layer), or an inherited legacy Erdiko application?
2. If legacy: what is the business criticality and the cost of a strangler migration to Laravel versus maintaining a fork?
3. What PHP version and Laravel version must we support, and does a composer why-not check confirm hard conflicts?
4. Are we willing to own security patching for an archived dependency, and who signs off on that risk?
5. Is the goal code reuse, pattern reuse, or license-driven extraction (MIT permits vendoring)?

Integration Approach

Stack fit. Treat erdiko/core as incompatible with a Laravel-first stack. It is a framework kernel, and Laravel already supplies a superior container, router, config repository, and view engine. There is no justified case for runtime inclusion in a greenfield or actively maintained Laravel codebase.

Migration path. Two viable paths, both non-trivial:

• Greenfield / Laravel-native: do not install. Instead, mine the package for patterns — its module bootstrapping and lightweight config layering — and reimplement those idioms using Laravel service providers, the config repository, and package discovery. This yields the conceptual benefit with zero dependency risk.
• Legacy Erdiko application: plan a strangler-fig migration to Laravel. Route traffic at the web server or a facade layer, migrate module by module, and freeze new feature work in Erdiko. Do not attempt side-by-side runtime integration of both kernels in one process.

Compatibility. Expect hard blockers: PHP version constraints, Symfony/PSR version pins, and the absence of Laravel auto-discovery. Any attempted coexistence requires a composer why-not audit and likely replace/provide hacks, which are fragile and should be rejected as a production strategy. Vendoring selected MIT-licensed files into an internal namespace is the only defensible reuse mechanism, and only with tests and a documented provenance note.

Sequencing.

1. Discovery: confirm the need (utility vs. legacy app); inventory any existing Erdiko usage and its blast radius.
2. Risk gate: security and architecture review sign-off on either "no runtime dependency" or "fork-and-own."
3. Pattern extraction (if greenfield): reimplement required concepts as a first-party Laravel package with tests.
4. Legacy migration (if applicable): establish the facade/routing seam, migrate lowest-coupling modules first, decommission Erdiko incrementally.
5. Exit criteria: zero references to erdiko/core in composer.json, CI dependency audit clean.

Operational Impact

Maintenance. Upstream maintenance is zero — archived, no releases since 2017, no issue triage. Any adoption transfers full maintenance burden to the adopting team, including security patching of the package and its transitive dependencies. For a TPM, this is an unbudgeted, perpetual headcount commitment and should be priced explicitly against the cost of rewriting the equivalent functionality.

Support. No vendor, no active community (18 stars), no documented support channel. Incident response would rely entirely on internal knowledge, which creates a single-point-of-failure risk if the original integrator leaves.

Scaling. The package itself is core scaffolding, so scaling characteristics are inherited from the host application rather than the library. The operational concern is not throughput but observability: 2017-era PHP code predates modern logging, tracing, and OpenTelemetry conventions, so instrumenting it in a modern SLO-driven environment requires bespoke work. It also lacks the async/queue integration patterns expected in scaled Laravel deployments.

Failure modes.

• Dependency resolution failure at install or upgrade time (most likely outcome).
• PHP runtime fatals on 8.x due to removed/deprecated language features.
• Silent security drift — no CVE feed, no patch path, exposure accumulates invisibly.
• Knowledge concentration — undocumented framework idioms and a shrinking pool of engineers who have seen Erdiko.
• Migration stall — partial adoption leaves a dual-kernel architecture that is harder to operate than either endpoint.

Ramp-up. Low return on investment. Laravel engineers gain nothing transferable from learning Erdiko; the idioms diverge from Laravel's container and lifecycle. Ramp-up cost is therefore pure overhead, justified only if the team is inheriting a live Erdiko application, in which case the ramp-up should be framed as a migration-readiness exercise rather than skills investment in the framework itself.

TPM recommendation. Do not adopt erdiko/core as a dependency in any Laravel or modern PHP codebase. Approve it only as a read-only reference for pattern extraction, or as the temporary substrate of a funded legacy migration with a defined decommission date. The archived status, 2017 release cadence, and framework-level coupling make the total cost of ownership materially higher than reimplementing the required functionality on Laravel's native primitives.