Core Laravel Package

Getting Started

Before writing a line of code, be clear about what this package is: honey-comb/core is not a Laravel package — it is the core of a separate, lightweight PHP framework. You do not composer require it into a Laravel app and expect service providers or facades. A Laravel developer "leverages" it in one of three ways: as a study of how a container/router/middleware pipeline is built, as the basis of a small standalone service, or as a source of patterns to port into Laravel.

Minimal steps to get productive:

1. Install it in a scratch project, not your app. composer require honey-comb/core in a fresh directory so it doesn't collide with Laravel's autoloading or Illuminate namespaces.
2. Read the source in this order — it's the only real documentation (last release was 2019 and the repo is archived, so there is no maintained docs site):
   • The dependency injection container class first. Everything else (routing, middleware, controllers) is resolved through it.
   • The router and route definition API.
   • The request/response objects and the middleware pipeline.
   • The bootstrap/entry point that ties them together.
3. First use case: stand up the smallest possible "hello world" — bootstrap the container, register one controller or closure, map a single GET route, and dispatch a request through the pipeline to get a response. This single loop (container → route → controller → middleware → response) is the whole mental model; once you've traced it end to end, the rest of the package is detail.

Because dependents are zero and release activity stopped in 2019, treat the README/description.md as a map, not a manual, and let the actual class signatures be your source of truth.

Implementation Patterns

Container-first wiring. Register every service, controller, and collaborator in the DI container rather than instantiating with new. This mirrors Laravel's service container but without the magic: bindings are explicit and replaceable. A practical pattern is to keep a single bootstrap/registration file that maps interfaces to concrete implementations so you can swap them per environment.

Routing + middleware as the request lifecycle. Define routes and attach middleware to them the same way you'd reason about Laravel middleware. The important adaptation: in Laravel you get a lot for free (route model binding, groups, naming); here you assemble those behaviors yourself via middleware. Treat middleware as the primary extension point for cross-cutting concerns (auth, logging, input normalization), exactly as you would in Laravel but with less built-in sugar.

Modular composition over a monolith. The package's stated philosophy — explicit, replaceable framework code composed from independent modules — maps cleanly onto how you'd structure a Laravel app with domain modules. If you adopt the package, keep features in self-contained modules that register their own routes and container bindings, and avoid letting modules reach into each other's internals.

Pattern porting (the most common real-world use for a Laravel dev). You can read this package to sharpen your understanding of what Laravel abstracts: how a container resolves and autowires dependencies, how a middleware pipeline short-circuits, how request/response flow through dispatch. Extract those as teaching/architecture patterns rather than runtime dependencies.

Isolated testing. Because the container and router are small and explicit, you can instantiate them directly in unit tests without booting a full application — a lighter loop than RefreshDatabase-style Laravel tests. Use this to test route resolution and middleware behavior in isolation.

Standalone microservice. If you build a small service and genuinely don't want Laravel's footprint, use this core to define routes and wire services, keeping the deployment Composer-only with no framework bootstrap ceremony.

Gotchas and Tips

• Archived and unmaintained. Last release 2019-08-29, repository archived, zero dependents. Pin the exact version, vendor/commit-lock it, and assume no security patches or PHP-version updates. Expect friction on modern PHP (7.x-era code) — check for deprecations and removed functions before committing.
• No ecosystem, no Stack Overflow. With 0 dependents you are effectively the only support channel. Budget time to read source when something is unclear; there is no community to fall back on.
• It is not a Laravel integration. No service provider, no facade, no config publishing, no Illuminate compatibility. Do not try to load it inside a Laravel app expecting them to share a container; keep them in separate projects.
• Docs are thin. The description.md/README describes capabilities, not APIs. Verify class names, method signatures, and namespace layout by inspecting the source before writing against them — don't assume Laravel-like method names (bind, singleton, get) without checking.
• You build the conveniences yourself. Route model binding, named routes, route groups, validation, and ORM-style access are not provided by the core. Plan to implement or add them via middleware/modules.
• Debugging is bare. There's no debug toolbar or detailed exception pages like Laravel's. Lean on Xdebug, var_dump, and structured logging inside middleware; add a try/catch around dispatch during development to surface errors.
• Extension points to lean on: the container (swap implementations), middleware (cross-cutting behavior), and bootstrapping (environment/config wiring). These are your seams for adapting the framework without forking it.
• Migration awareness. If you prototype on honey-comb/core, keep business logic in plain, framework-agnostic classes so a later move to Laravel (or anything else) is a routing/bootstrap change, not a rewrite — which aligns with the package's own "explicit and replaceable" philosophy.