- How do I install Esplora Spire in a Laravel application?
- Install the package with Composer using composer require esplora/spire. Because Spire supports Laravel package auto-discovery, the service provider is registered for you and no manual edits to config/app.php are required on supported versions. After installation, publish the configuration file if you want to override the defaults, then continue building on your existing architecture.
- Does esplora/spire support Laravel auto-discovery, or do I need to register the service provider manually?
- Spire is built around Laravel's auto-discovery convention, so the service provider is registered automatically once the package is installed through Composer. You would only need to add it to the providers array in config/app.php if you have disabled package discovery in your application. Manual registration is otherwise unnecessary and can lead to duplicated bindings.
- How do I publish the Spire configuration file?
- Spire ships a publishable configuration file that follows standard Laravel conventions. Run php artisan vendor:publish and choose the Spire service provider entry to copy the config into your application's config directory. Commit the published file to version control so environment-specific changes stay visible during code review.
- Which Laravel versions does esplora/spire support?
- The package is designed around standard Laravel service provider, configuration, container binding, and facade conventions, so it targets modern Laravel releases. The exact version constraint is declared in the package's composer.json, so check that file or the Packagist listing before upgrading your framework. Always verify compatibility in a staging branch before bumping Laravel in production.
- How do I extend Spire with project-specific behavior?
- Spire exposes extensible contracts and hooks so you can add your own behavior without touching vendor code. Implement the relevant contract in your application and bind it through a service provider so the container resolves your version. This keeps customizations isolated, upgrade-safe, and easy to test.
- Can I use Spire's container bindings and facades in my own application code?
- Yes. Spire integrates with Laravel's container and provides facade access, so you can resolve instances from the container or call the facade from framework-level code. For application and domain logic, prefer constructor injection over facades because it keeps dependencies explicit and tests simpler. Reserve facades for controllers, middleware, and other glue code.
- How do I test code built on top of Spire in my Laravel test suite?
- Spire's APIs are intentionally simple and testable, so you can cover them with Laravel's normal testing helpers. Bind a fake or mock implementation of the relevant contract in the container inside your test setup to isolate your code from real behavior. No additional test harness or custom bootstrapping is required.
- Does Spire add overhead or heavy dependencies to a production Laravel app?
- Spire is deliberately minimal, with a small runtime footprint and very few dependencies beyond Laravel itself. Its service provider performs only the standard registration and binding work during application boot, so there is no extra infrastructure to deploy or maintain. This makes it a low-risk addition to an existing production application.
- What is the difference between Spire and writing my own Laravel package scaffolding?
- Spire gives you a clean, Laravel-native foundation with auto-discovery, publishable configuration, contracts, and hooks already in place, which saves you from rebuilding that plumbing yourself. Rolling your own scaffolding gives maximum control but costs more setup and maintenance time. If you want a thin, convention-driven starting point rather than a large feature suite, Spire is the lighter option.
- Who maintains esplora/spire and how should I manage updates?
- Spire is maintained by Esplora and developed in the public GitHub repository linked from the package listing, where releases and issues are tracked. Review the changelog before upgrading and pin a version constraint in composer.json so upgrades are deliberate. Because the package is small and framework-conventional, upgrades are typically low effort.