Core Laravel Package

Product Decisions This Supports

• Build vs. buy vs. fork for internal low-code tooling. If your roadmap includes admin-configurable forms, entity builders, or tenant-specific schemas, feral/core is a working PHP reference implementation of the metadata-driven pattern. The 1.0.0 release sharpens the decision: the core is now framework-agnostic, so the question is no longer "adopt a Laravel package" but "do we adopt a portable metadata engine and write our own framework glue?" Apache-2.0 keeps forking on the table with no legal friction.
• Architecture direction for schema-driven CRUD. The package's enduring value is as a worked example of separating resource definitions (metadata) from rendering and persistence. Removing the Symfony and Docker coupling makes that separation explicit and makes the abstraction easier to reason about in isolation — useful for the design review question: should our next admin surface be hard-coded per entity, or driven by declarative definitions we can version and ship without a deploy?
• Lock-in and portability posture. A 1.0.0 that deliberately strips framework bindings is a datapoint in favor of a portable domain core with thin, replaceable adapters. That is a defensible architectural principle independent of whether we ever use this code, and it's worth citing in design standards.
• Roadmap sequencing for a "no-code" capability. Before committing a quarter to a low-code feature, this package lets you pressure-test whether the abstraction holds up against your actual domain. A two-week spike against one real customer workflow is cheaper than a six-month platform bet — and now the spike also tells you what integration cost you incur, since the package no longer ships any.
• Prototyping and internal tooling use cases. Best fit remains internal or low-stakes surfaces: back-office screens, ops tooling, configurable intake forms — not customer-facing, revenue-critical paths.
• Vendor/technology risk assessment. The 1.0.0 milestone signals intended API stability, but it is a single release from a project with 3 stars, 0 dependents, and a prior release in November 2022. Treat "1.0.0" as an author's declaration, not evidence of hardening. This informs procurement and engineering-standards decisions about what qualifies as an approved third-party library.

When to Consider This Package

Consider it when:

• You want a head start on the data model and abstraction design, and you're prepared to vendor or fork the code rather than track upstream. Apache-2.0 permits this cleanly.
• You need or prefer a framework-agnostic metadata core — the 1.0.0 release removes Symfony and Docker, so the library is no longer tied to a specific runtime. That makes it more interesting if you run mixed PHP stacks or expect to change frameworks.
• Your team is comfortable writing the integration layer themselves: routing, persistence, DI wiring, and rendering adapters are now explicitly your responsibility. Budget for that, not just for reading the source.
• You have an internal-tooling use case where a stale dependency is a maintenance annoyance rather than a customer-facing risk.
• You're doing a timeboxed spike to validate a low-code direction before funding it, and you want the spike to include a realistic estimate of adapter work.

Look elsewhere when:

• You want a Laravel-native drop-in. The removal of Symfony components means the previous (implicit) alignment with Laravel's own foundations is gone. On Laravel you will be writing glue that the old build gave you for free. Do not assume "PHP library" means "works with Laravel out of the box."
• You need an actively maintained dependency. One new release does not create a maintenance cadence. There is still no security-patch pipeline, no bug-fix rhythm, no dependents, and no one to escalate to. That remains disqualifying for production-critical surfaces.
• You need ecosystem maturity. If the requirement is admin panels, form builders, or CRUD scaffolding on Laravel, mature alternatives (Filament, Nova, Orchid, Statamic, or a headless builder) give you documentation, a hiring pool, and support that this cannot.
• You need a documented, stable public API. A 1.0.0 with a breaking restructure and no published migration guidance or docs is a signal that the API is stable in intent, not necessarily in practice. Expect to read the source.
• You need multi-tenant, permissions, or audit guarantees spelled out contractually — you'd be inheriting that responsibility entirely, and now the framework-level plumbing as well.

Net PM read: unchanged in kind, sharper in scope. Evaluate as a reference architecture and prototyping accelerator, not as a foundational dependency. The 1.0.0 release makes it a cleaner pattern to learn from and a worse thing to install, so budget a spike with explicit adapter-cost estimation, not an integration.

How to Pitch It (Stakeholders)

To executives: This is a free, permissively licensed (Apache-2.0) PHP core for no-code/low-code tooling. Its new 1.0.0 release deliberately decouples it from any single framework, which makes the underlying design more portable and more useful to us as a reference — but it also means it ships no integration, so adopting it means building the plumbing ourselves. It is still not a production dependency: effectively no community, no dependents, and a multi-year gap before this release. Its value is strategic and cheap: it lets us validate whether a low-code capability is worth building, at the cost of a short engineering spike rather than a platform program — with the added benefit that the spike now produces a realistic estimate of our own integration cost. Recommendation: fund a timeboxed prototype against one real internal workflow, and use the results to decide build vs. buy before committing roadmap.

To engineering: Treat feral/core as a pattern library, and treat 1.0.0 as a reset of its integration story. Read it for how it separates resource metadata from rendering and persistence — that's the reusable idea, and it's now cleaner because the framework coupling has been stripped out. Do not add it as a Composer dependency. If the spike succeeds, we vendor or fork under Apache-2.0 and own the code outright, including the adapter layer we write on top, with the understanding that we inherit all maintenance, security, and documentation obligations. Note that the Symfony removal is a real breaking change: any prior internal notes or proof-of-concept branches that assumed the bundled stack need to be re-baselined. Success criteria for the spike: one internal workflow shipped on the abstraction, a measured delta in time-to-build versus hand-coded screens, a costed estimate for the framework-adapter layer, and a clear answer on whether the abstraction survives contact with our real domain model.