Weave Code
Extension Laravel Package
orchestra/extension
Orchestra Extension adds modular extension support to Laravel, letting you package features as self-contained modules with manifests, service providers, and activation controls. Manage, activate, and migrate extensions through a central API for cleaner, modular applications.
Orchestra/Extension provides a lightweight foundation for building and managing modular extensions within Laravel applications. It offers the base service provider, configuration, and lifecycle hooks needed to register, boot, and organize extension packages—making it easy to develop reusable modules that integrate cleanly with the Orchestra Platform ecosystem.
- Base ExtensionServiceProvider for streamlined registration
- Extension discovery and activation lifecycle support
- Configurable manifest and metadata handling
- Seamless integration with Laravel's service container
- Designed for reusable, modular package architecture
Frequently asked questions about Extension
- What is orchestra/extension used for in a Laravel application?
- It provides a lightweight foundation for building and managing modular extensions as managed Composer packages with manifests, service providers, and an activation lifecycle. It handles detection, activation, deactivation, dependency-ordered boot, plus orchestration of per-extension migrations and asset publishing. It is a horizontal lifecycle layer, not a domain package, so it helps make a modular monolith viable without redeploying per feature.
- How do I install orchestra/extension?
- Install it with Composer as orchestra/extension, then wire the extension service provider and Orchestra conventions into your app. On vanilla Laravel that means reproducing config/orchestra/extension.php, the path scan root, and the orchestra.json manifest schema. Inside Orchestra Platform it is already present transitively, so the main decision is to pin and own it deliberately.
- Does orchestra/extension support Laravel 9, 10, or 11?
- The last visible milestone is Laravel 8, so on Laravel 9 and newer the honest framing is a fork rather than a direct adoption. You should run a Composer dry-run against your target PHP and illuminate/* versions before committing, because if that check fails nothing downstream matters. Upgrading the host application means patching the dependency yourself.
- Do I need orchestra/foundation to use orchestra/extension?
- No, but the experience differs sharply. Inside Orchestra Platform, orchestra/foundation is already installed and the extension package is present transitively, so conventions and conditional provider registration come for free. On standalone Laravel you can wire it up, but you absorb the coupling cost by hand-reproducing Orchestra's conventions.
- How does extension activation and deactivation work?
- The package provides a registry with four primitives: detect, activate, deactivate, and dependency-ordered boot. Activation records are the control plane, while Composer autoload maps are a separate source of truth, so they can desynchronize. The canonical failure is an extension that appears active but throws class-not-found.
- Can orchestra/extension handle per-tenant or per-tier extension activation?
- The stock factory persists one global activation set, so per-tenant or per-tier gating is not available out of the box. You must override the Factory contract early if that is a real requirement. Retrofitting tenant-aware activation after extensions already exist against global state is expensive.
- What are the production risks of using orchestra/extension?
- Concrete risks include the Laravel 8 framework ceiling, caching interactions where discovery results are cached and config:cache can freeze extension configs at build time, and global activation state. Silent partial activation is also possible: an extension can activate and register its provider while failing migrations or publishing, surfacing days later far from the cause. Plan for state drift between activation records and Composer autoload maps.
- What alternatives are there to orchestra/extension for modular Laravel apps?
- On modern standalone Laravel, nwidart/laravel-modules covers scaffolding, Laravel's native package discovery handles registration, and a small application-owned enabled_extensions table can manage activation. That combination covers roughly 80 percent of the benefit with a cleaner ownership story. Orchestra/Extension is strongest when you are already inside Orchestra Platform.
- How are migrations and asset publishing handled for extensions?
- The package orchestrates per-extension migrations and asset publishing as part of the extension lifecycle. That is useful, but it also creates the silent partial activation risk: a provider may register successfully while its migrations or publishing fail. You need deployment checks that verify both activation state and migration or publish success.
- Is orchestra/extension actively maintained and safe for third-party plugins?
- The visible ownership signals are weak: zero stars, zero listed dependents, score 0.3, and a single-maintainer profile with no support contract, release cadence, or security process. Treat it as a reference implementation rather than a vendor relationship. Also note that extension here means a managed Composer package with a manifest, not a sandboxed plugin; there is no sandboxing, versioned host-to-extension API contract, or signed registry, so third-party code safety must be scoped as separate work.
Weaver
How can I help you explore Laravel packages today?