- Is leapt/core-bundle a Laravel package?
- No. leapt/core-bundle is a Symfony bundle, not a Laravel package. It depends on Symfony kernel boot, a Bundle subclass, a DI extension, a configuration tree, compiler passes, and service tags. Laravel has no equivalent registration path, so the architecture fit is poor for a Laravel-first estate.
- Can I install leapt/core-bundle in a Laravel application?
- You can add it with Composer, but the bundle wiring, configuration, and defaults will not engage in Laravel. Laravel ships several Symfony components such as HttpFoundation and Console, so individual classes may autoload and run in isolation. Expect an installable but inert result unless the package is mostly framework-free plain PHP.
- What features does leapt/core-bundle provide?
- The bundle aims to reduce repetitive backend work around data lists with search, file and image uploads, pagination, RSS, and SEO. It provides shared core services, utilities, and integration helpers for Leapt-based applications. The practical value for a Laravel team is in individual classes that solve a specific problem, not the bundle as a whole.
- What Laravel versions does leapt/core-bundle support?
- There are no official Laravel version constraints because this is a Symfony bundle. Check composer.json for symfony/framework-bundle requirements, the PHP floor, and any symfony/* constraints that could pin your framework upgrade path. Laravel 10 and 11 already ship Symfony 6 and 7 components, so component-level alignment is plausible, but the bundle API layer is the blocker.
- How do I install and configure leapt/core-bundle?
- In Symfony you would require the package, register the bundle in bundles.php, and configure it through config/packages. Laravel has no equivalent bundle registration path, so there is no supported install-and-configure route. If you extract code, replace Symfony DI with Laravel service-provider bindings and keep configuration explicit in your own config files.
- Is leapt/core-bundle actively maintained?
- Adoption signals are low: roughly 26 stars, 0 dependents, and no public production usage, with a bus factor of effectively one. The release dated 2026-09-25 is future-dated, which suggests a metadata or tagging anomaly, so verify with composer show -a and the git tag graph. Pin an exact version or commit SHA and do not count on upstream as a patch source.
- How should I test leapt/core-bundle before using it with Laravel?
- Run a one-to-two-day spike: clone the repository, install it, run the test suite locally, inventory src/, and map dependencies on Symfony framework services. Check whether there is CI, test coverage, or static analysis, and confirm the PHP and Symfony version constraints. Wrap any extracted code behind an internal adapter interface, back it with tests, and ship it behind a feature flag.
- What are the alternatives to leapt/core-bundle for Laravel?
- Use Laravel-native packages and framework features for pagination, file and image uploads, RSS, SEO, and searchable lists. Laravel's paginator, filesystem, validation, and event system cover most of the same ground without a Symfony bundle layer. For a package this size, a native reimplementation often fits in one to three developer-days.
- Is leapt/core-bundle safe and production-ready for a Laravel app?
- The MIT license is permissive, so forking or vendoring is legally clean, which lowers the downside. However, there is no public production usage, no vendor, no SLA, and minimal community support, and the bundle touches security-sensitive surfaces such as input handling, file I/O, HTTP, and templating. Do not make it a production dependency of a Laravel application; extract only the classes you need and keep provenance and the MIT header.
- How do I migrate or extract code from leapt/core-bundle into Laravel?
- Fork the repository into an internal namespace and copy only the specific classes that solve your problem. Replace Symfony DI with Laravel service-provider bindings and replace the Symfony event dispatcher with Laravel events or plain observers. Keep the original MIT header, record provenance and divergences, and keep a native Laravel rebuild as the fallback if the extracted code proves too coupled.