- What is honed/core used for?
- honed/core is the shared foundation package for the Honed Laravel ecosystem. It is described as providing shared contracts, service providers, configuration, and common utilities that the sibling Honed modules build on, so it is a base layer rather than a feature package. You would install it when adopting Honed modules or when you want the same conventions in your own modular Laravel application. The exact class and trait inventory is not spelled out in the overview, so review the source before relying on specific helpers.
- How do I install honed/core with Composer?
- Install it with Composer using the package name published on Packagist: composer require honed/core. Confirm the vendor segment first, because the Composer name honed/core and the GitHub repository honedlabs/core do not match exactly, and requiring the wrong name will fail. Because this is a shared-utilities library, no scaffolding or migration step is expected beyond normal Laravel package discovery.
- Which Laravel and PHP versions does honed/core support?
- The package targets Laravel applications on a modern PHP runtime, with PHP 8.1 or newer being a reasonable assumption for anything released recently under a Laravel-ecosystem banner. The overview does not publish an explicit compatibility matrix, so check composer.json for the actual php and illuminate/support constraints before upgrading your application. Pin a tested version in composer.json if you need to stay compatible across Laravel majors.
- Does honed/core use Laravel package auto-discovery, or do I register providers manually?
- Laravel packages normally declare their providers under extra.laravel.providers in composer.json, which means discovery handles registration and you do not touch config/app.php. If discovery is disabled in your application, or the package does not declare providers, register them explicitly in the providers array. Run php artisan about after installing to confirm which providers were loaded.
- How do I publish and customize honed/core configuration?
- Configuration is normally published with php artisan vendor:publish using the tag the package declares, and then edited in config/. Because honed/core is a shared foundation, its configuration may be deliberately minimal and mostly consumed by sibling Honed modules rather than tuned per application. Only publish and modify it if the shipped defaults do not fit your setup.
- Does honed/core duplicate helpers already in illuminate/support?
- There is a real risk of overlap, since shared-utilities packages often ship string helpers, array helpers, and DTOs that duplicate what illuminate/support already provides. Before adopting it, compare the package's utility surface against what laravel/framework gives you for free. Reusing framework helpers keeps your dependency graph smaller and avoids two competing conventions in one codebase.
- Is honed/core production-ready given its low star and download counts?
- Treat it as unproven rather than unsafe. Zero stars and no known dependents means there is no public evidence of production use, and shared-utilities packages are exactly where pre-1.0 breaking changes tend to land. A prudent posture is to wrap any calls you make in your own thin adapter so the package can be swapped out without touching application code.
- How should I test an application or package that depends on honed/core?
- Because honed/core is mostly contracts, providers, and helpers, most tests only need a booted Laravel test case, either through Orchestra Testbench or your application's own TestCase. If you are testing a package that depends on it, add it as a require-dev dependency and let the service providers load through discovery. Mock the specific contracts you consume rather than the whole package.
- What is honed/core's versioning and breaking-change policy?
- The overview states no SemVer posture or support window, so assume pre-1.0 rules apply until the maintainers publish a policy. In practice that means minor releases may contain breaking changes and you should read the changelog before upgrading. Pin to a caret range you have actually tested and treat upgrades as deliberate maintenance work.
- What are alternatives to honed/core for shared modular Laravel utilities?
- If you only need a common base for your own modular Laravel packages, laravel/framework plus a lightweight helper such as spatie/laravel-package-tools for provider and config wiring covers most of the same ground. honed/core makes the most sense when you are already adopting Honed modules and want a consistent base across them. Weigh the reuse benefit against the maintenance cost of an extra dependency with little public track record.