Weave Code
Croft Laravel Laravel Package
usecroft/croft-laravel
Laravel integration for Croft, making it easy to bring Croft content into your Laravel application. Work with content types and entries using familiar Laravel patterns, so you can build dynamic, content-driven sites with less boilerplate.
MCP server for all of your Laravel projects - better AI pair programming
Frequently asked questions about Croft Laravel
- How do I install usecroft/croft-laravel in a Laravel application?
- It is a Composer package, so installation is done through Composer require, and the package is expected to auto-discover via Laravel package discovery with a single service provider. The README excerpt available for this review was empty, so confirm the exact require command, any config publishing step, and required environment variables against the repository before wiring it in. The technical assessment found no non-standard infrastructure requirements, so a conventional Laravel app using the service container, config system, and artisan should be sufficient.
- Which Laravel versions does croft-laravel support?
- No formal support matrix was available in this review. The only compatibility evidence is an upgrade example covering a single Laravel version pair, which is encouraging but does not prove which versions are covered in CI. Check the package's composer.json constraints and CI matrix before committing to a specific Laravel version.
- What does conditional tool registration in croft-laravel 0.6.0 actually do?
- Version 0.6.0 adds conditional tool registration, meaning a tool can be gated at registration time instead of being exposed unconditionally. That lets you gate tools by environment, a config flag, a capability probe, or tenant context. It is the first architecturally meaningful signal in the release line because it turns tool exposure into a policy decision rather than a fixed list. The release note does not document the condition's exact contract, so treat the API as provisional until you read the source.
- Is the registration condition evaluated at boot time or on every tool invocation?
- This review could not determine that from the changelog, and it matters a great deal. Boot-time evaluation supports deploy-time policy, while per-invocation evaluation is what you need for request-scoped or tenant-scoped gating. Verify it in the package source or its tests before designing multi-tenant policy around it. If it is boot-only, treat it as a deployment configuration mechanism rather than runtime authorization.
- What happens when a croft-laravel registration condition is unset or throws an exception?
- The 0.6.0 release note says nothing about defaults, which is the most important missing detail for a security-relevant boundary. A misconfigured condition could silently expose a tool you intended to hide, or silently hide a tool you depend on. Confirm whether the behavior is fail-open or fail-closed, whether it is configurable, and add your own assertions around both cases before relying on conditional registration in production.
- Is usecroft/croft-laravel stable enough for production at version 0.x?
- The package is pre-1.0, and at 0.x the maintainers reserve the right to ship breaking changes in minor releases, so any registration API you build on is provisional. The 0.5.0 to 0.6.0 bump added a feature without documented migration notes or deprecations, which limits how much blast radius you can assess from release notes alone. A reasonable approach is to pin an exact version, wrap the integration behind your own abstraction, and upgrade deliberately. No published 1.0 timeline or stability policy appeared in the material reviewed.
- Do I need to register the Croft service provider manually in Laravel?
- Architecturally the package is described as a low-ceremony fit that should auto-discover through Laravel package discovery and expose registration through a config or provider surface. Manual registration is typically only necessary if discovery is disabled or you need to control provider ordering. Confirm against the repository README, since the excerpt available here was empty. The package also appears additive, registering tools without taking over routing, queueing, or auth, so it can be adopted in one bounded slice of an application.
- How do I test that my Croft tools are registered correctly?
- Start by reading the package's own tests, since the review flags uncertainty over whether the condition contract and edge cases are actually covered. In your application, assert the registered tool set for each environment and config permutation, including the unset-condition and throwing-condition cases. Laravel's container and config make it practical to boot the provider under different configurations inside a test. Keep those assertions in CI so a minor upgrade cannot silently change what is exposed.
- Does conditional registration interact with any tool discovery or registration caching layer?
- This was flagged as an open question: if the package caches registrations or tool discovery results, it could serve a stale registration set that does not reflect the current condition. The risk is highest if conditions are evaluated per request or per tenant. Check whether registrations are cached, how the cache is keyed, and how it is invalidated when config or conditions change.
- Who maintains croft-laravel and how responsive is the project?
- The package is published under the usecroft vendor name, but bus factor and issue/PR responsiveness were listed as unresolved questions in this review. A small team behind a security-relevant registration surface is a real risk for a pre-1.0 dependency. Review the repository's commit history, issue activity, and release cadence, and keep a fork-or-replace path open. Pinning exact versions limits the damage if maintenance slows.
Weaver
How can I help you explore Laravel packages today?