Weave Code
Installer Laravel Package
spora-ai/installer
A Laravel installer package for Spora AI that streamlines setup by publishing config and assets, registering service providers, and running required migrations, so you can get a new Spora AI integration running quickly from a single Artisan command.
Composer plugin for Spora
Frequently asked questions about Installer
- What does the spora-ai/installer Composer plugin actually do?
- It is a Composer plugin, not a runtime Laravel package, that hooks Composer's post-package-install and post-package-update events. When Spora-typed packages are installed, it relocates them out of vendor/ into convention-based paths such as plugins/{$name}/, public/spora/, and public/plugins/{$slug}/. It is also described as publishing config and assets, registering service providers, and running required migrations so a Spora AI integration can be set up from a single Artisan command.
- How do I install spora-ai/installer in a Laravel application?
- Require spora-ai/spora-core and spora-ai/installer with Composer, then add the installer to the allow-plugins section of your root composer.json. Because this is a Composer plugin, Composer 2.2 and later blocks it by default until you explicitly allow it, so this is a hard gate rather than optional hardening. Once allowed, a composer install or update fires the plugin and the Spora setup command does the rest.
- Why is the Spora installer not running after composer require?
- In most cases the allow-plugins gate is the culprit. Since Composer 2.2, plugins stay inactive unless listed under config.allow-plugins in the root composer.json, so add the entry and rerun the install. Also confirm you are on Composer 2.x with composer-plugin-api support, and that a real post-package-install or update event fired rather than a cached or lock-only run.
- Is spora-ai/installer a replacement for composer/installers or installer-paths?
- No. The generic, battle-tested solution is to declare custom package types and installer-paths in your root composer.json, which is exactly how composer/installers works. This plugin's value is zero-config defaults for the Spora ecosystem rather than new capability, which means the install-time risk is taken on for convenience. If you only need to relocate a package or two, a few lines of installer-paths configuration may serve you better.
- Which Laravel and PHP versions does spora-ai/installer support?
- The plugin requires Composer 2.x with composer-plugin-api and expects PHP version parity with spora-core, so its practical PHP and Laravel range follows spora-core's Composer constraints. Check spora-core's require block and release notes before assuming support for a specific Laravel major. Because the installer executes at install time rather than at runtime, framework mismatches usually surface through spora-core, not the plugin itself.
- Where does spora-ai/installer place files, and can I customize those paths?
- Placement follows hardcoded conventions: plugins/{$name}/, public/spora/, and public/plugins/{$slug}/. The technical evaluation notes the paths are not configurable through something like extra.spora-installer, which suits a first-party companion package but removes flexibility for monorepos or non-standard public roots. If you need custom destinations, installer-paths in your root composer.json is the escape hatch.
- Will moving packages to plugins/ break Composer autoloading?
- It can, because Composer's autoloader still expects those classes under vendor/. Moving files creates a dual-source-of-truth situation, and spora-core must register PSR-4 roots for plugins/* and public/plugins/* for everything to resolve. If it does not, you get class-not-found errors at runtime rather than at install time, so verify autoload registration before trusting the install to be complete.
- What happens on composer update --lock-only, uninstall, or a failed install?
- The documented behavior covers install and update events only, which leaves the classic lifecycle gaps for this pattern: uninstall cleanup, lock-only runs, warm CI cache restores, and partial-failure rollback. Those cases can leave orphaned directories under plugins/ and stale assets under public/spora/ or public/plugins/. Test each one explicitly in a throwaway application before relying on the installer in automation.
- Is spora-ai/installer safe for CI pipelines and atomic-deploy production setups?
- Treat it with care, because a Composer plugin runs with full filesystem write access at install time and, with zero stars, zero dependents, and no public audit, the code path that writes into your application tree is unverified by the community. Pin an exact version and require a reviewed commit or tag before it enters CI. Also confirm behavior under symlinked atomic releases, where public/spora/ and plugins/ must be shared rather than release-local, and watch copy-versus-symlink semantics, Windows path separators, and read-only public/ directories in containers.
- Who maintains spora-ai/installer, and is it production-ready?
- It is a first-party companion to spora-core, so its support contract is tied to that package's release cadence rather than to a broad community or a public changelog. The technical evaluation flags zero stars, zero dependents, and no third-party audit of the install-time code, so there is no external verification of what runs during composer install. For a Laravel app that has adopted the Spora ecosystem end to end, the co-designed install ergonomics make sense; for vanilla Laravel with a few custom packages, it adds a dependency and a code-execution surface for marginal gain.
Weaver
How can I help you explore Laravel packages today?