Core Laravel Package

Getting Started

Because honed/core is billed as shared utilities for the wider Honed ecosystem, treat it as plumbing rather than a feature package. Your first job is orientation, not configuration.

Install it

composer require honedlabs/core

The service provider is almost certainly auto-discovered (Laravel package convention). If not, add it manually:

// bootstrap/providers.php (Laravel 11+) or config/app.php
Honed\Core\CoreServiceProvider::class,

Where to look first, in order:

1. src/ — scan the directory names. Shared-utility packages tend to organise by concern: Concerns/ (traits), Support/ (helpers, value objects), Providers/, Facades/, Testing/.
2. composer.json — the autoload block tells you the root namespace and whether helpers are files-autoloaded (e.g. "files": ["src/helpers.php"]). That determines whether functions are globally available or namespaced.
3. src/CoreServiceProvider.php (or equivalent) — the register()/boot() methods are the package's real table of contents. Anything it binds, merges, or publishes is intentional public surface.
4. README.md / CHANGELOG.md — with 0 stars and 0 dependents, the changelog is your best source of truth for what's stable.
5. config/core.php if it exists — publish it and diff against the package copy to see what's actually configurable.

First use case

The typical entry point for a shared-utilities package is a trait you can bolt onto an existing class. Look for something in Concerns/ (common shapes: HasMetadata, InteractsWithHoned, HasUuids, Filterable) and apply it:

use Honed\Core\Concerns\HasMetadata;

class Report
{
    use HasMetadata;
}

If there are global helpers (files-autoloaded), smoke-test one in php artisan tinker before wiring anything into application code. That single check tells you whether autoloading and the provider booted correctly.

Implementation Patterns

Depend on it, don't fork it. Since it's the shared layer of an ecosystem, the intended pattern is that sibling Honed packages (and your app) pull the same traits and base classes from core. Resist copy-pasting a utility out of core "just this once" — you'll diverge from every other package that expects the core version's behaviour.

Composition via traits is the primary workflow. Use the package's concerns on your own classes rather than extending package base classes where possible. Traits keep you off the inheritance ladder and survive minor-version refactors better than subclassing.

Bootstrapping through the provider. If core registers container bindings or macros, consume them through the container rather than instantiating utility classes directly:

// Prefer resolving so bindings can be swapped in tests
$utility = app(Honed\Core\Support\Something::class);

Config publishing pattern. Standard Laravel package shape — publish once, version the published file:

php artisan vendor:publish --provider="Honed\Core\CoreServiceProvider" --tag=core-config

Keep the published config in source control and review it on every composer update of core, because the package's mergeConfigFrom defaults can shift under you.

Testing integration. Shared-utility packages often ship Testing/ helpers or a base TestCase. If so, extend it in your own test suite so assertion helpers and fixtures stay consistent:

use Honed\Core\Testing\TestCase;

class MyPackageTest extends TestCase {}

Layering with the rest of the ecosystem. The realistic day-to-day pattern is: core provides traits/helpers → a higher-level Honed package (or your app) composes them → your feature code uses the composition. When debugging, follow that chain downward; if something behaves oddly in a sibling package, check whether core changed first.

Pin and isolate. In composer.json, constrain it tightly while the ecosystem is young:

"honedlabs/core": "^0.1"

and lean on composer.lock in CI so a silent minor bump doesn't rewrite shared behaviour across every package that depends on it.

Gotchas and Tips

Zero stars and zero dependents is a real signal. This is not a maturity judgement of the code — it's a warning that there's no community surface area: no Stack Overflow answers, no third-party bug reports, no blog posts. When something breaks, you are the first person to see it. Budget debugging time accordingly and read the source rather than searching for docs.

The release date looks anomalous. A 2026-07-06 last-release timestamp suggests either a mis-tagged clock, a pre-dated release, or metadata from a tag that hasn't actually shipped. Before relying on a version, verify it resolves:

composer show honedlabs/core --all
composer why honedlabs/core

If the version you expect isn't listed, pin to a commit hash temporarily.

Config merge vs. publish is a classic trap. mergeConfigFrom in register() only deep-merges arrays; scalar defaults and nested keys added in a later version may not reach your published config. After upgrading core, diff the published file against vendor/honedlabs/core/config/core.php.

Auto-discovery ordering. If core's provider must run before another package's provider (common when it registers macros or container bindings that siblings consume), auto-discovery ordering is not guaranteed. Register core explicitly in bootstrap/providers.php ahead of consumers, or have the consumer app()->register() it lazily.

Namespaced vs. global helpers. If composer.json autoloads a files entry, functions are global — check for collisions with existing helpers (str_*, array_*) before assuming a call resolves to core. Use function_exists() guards in your own wrappers.

Debugging checklist when behaviour is unexpected:

• php artisan about — confirms the provider is loaded.
• php artisan tinker → app()->getLoadedProviders() — confirms registration order.
• composer dump-autoload -o — fixes stale classmaps after a version change.
• vendor/honedlabs/core/src/ — read the actual method, not the docblock. With no community docs, source is authoritative.

Extension points to prefer. Container bindings and macros are safer extension points than subclassing package base classes — they survive internal refactors. If core exposes a facade, resolve the underlying binding and swap it in tests via app()->instance(...) rather than mocking the facade.

Treat the public API as unstable. With no dependents, there's no social pressure keeping method signatures stable. Wrap core utilities you rely on in a thin application-level adapter class; when core renames or reshapes something, you patch one file instead of every call site.