Core Laravel Package

Product Decisions This Supports

• Build vs. buy vs. skip — this is a "skip." At 18 stars, no release since April 2017, and an archived repository, erdiko/core fails the baseline viability check any PM should apply before a dependency enters the stack. The decision this package most directly supports is a documented no-go, which is itself a valuable artifact: it shows due diligence and gives the team a precedent for how abandoned dependencies are evaluated.
• Framework consolidation, not framework proliferation. Note the framing correction: this is not a Laravel package. Erdiko is its own PHP micro-framework, and erdiko/core is its DI container, routing, config, and view layer. Adopting it alongside Laravel means running two application kernels, two container conventions, and two upgrade paths. The PM decision is "one framework, deliberately chosen" — and Laravel already is it.
• Dependency policy and supply-chain hygiene. An archived MIT repo with no security response process is a standing risk item. Use this as a concrete example when drafting rules like "no dependencies without a release in 18 months" or "archived repos require an owner-approved exception." That policy decision has far more leverage than this specific package ever will.
• Legacy audit / inherited-codebase triage. The one genuinely useful application: if a team inherits an Erdiko-based app, this repo is the source of truth for what is inside it. That feeds a migration estimate — replacing a dead micro-framework core is a scoped, budgetable project rather than an open-ended unknown.
• Roadmap input for platform teams. If any internal service still runs Erdiko, this is a "plan the exit" line item, not a "modernize in place" line item. There is no upstream to modernize with.
• Not a use case: greenfield services, prototypes, internal tools, or anything with a multi-year expected lifespan. There is no scenario where starting here is cheaper than composer require laravel/framework or slim/slim.

When to Consider This Package

Consider it only under all of the following:

• You are maintaining an existing Erdiko application and need to pin, patch, or fork erdiko/core locally because nothing upstream will fix it.
• You need to read the code to understand behavior in an inherited system — as reference material, not as a dependency you add.
• You are doing a framework comparison or teaching exercise where an unmaintained 2017-era PHP micro-framework is the subject, and nothing ships to production.
• You have an air-gapped or frozen environment where the code is already vendored, cannot be changed, and the only task is documentation.

Look elsewhere — essentially always — when:

• Any new build. No PHP 8+ support guarantees, no security patches, no maintainer to escalate to. The blast radius of an unpatched request-handling and DI layer is your entire application surface.
• You are on Laravel or Symfony. Use the first-party container, router, and config. Reaching outside the framework for these primitives buys nothing and costs you upgrade compatibility.
• You need an actively maintained micro-framework. Slim, Laminas, or Laravel Zero cover the same ground with live maintainers. For individual components, Symfony and php-di are the safe picks.
• You need support, SLAs, or a vendor relationship. MIT + archived means community-only, and the community is effectively zero.
• You need a current LTS story. The last release predates modern PHP by several major versions; the migration cost to make it viable likely exceeds writing the equivalent code.

How to Pitch It (Stakeholders)

To executives (one paragraph): We evaluated erdiko/core, an open-source PHP framework core, and are recommending against adoption. It has 18 GitHub stars, no release since April 2017, and the repository is archived — meaning the maintainers have formally stopped work. There is no one to fix a security issue, no path to current PHP versions, and no support. The cost of adopting it is not the license (it's free, MIT) but the eventual forced migration off it, plus the risk of an unpatched request and dependency-injection layer sitting in front of our application. The only decision it drives is a negative one, and if we ever inherit a system built on it, we should budget a replacement rather than a repair.

To engineering: Treat this as reference-only. Do not add it to composer.json. It is not a Laravel package — it's a separate micro-framework, so pulling it in means running a second application kernel next to ours. If you encounter it in a legacy codebase, flag it as technical debt with a named owner; the exit is a rewrite of routing, container, and config wiring onto our standard stack, and that's a scoped project, not an afternoon. Use this evaluation as the worked example for our "archived dependency" policy: no releases in 18 months, or an archived repo, requires an explicit exception with an owner and a sunset date.