- What is orchestra/contracts and what does it actually do?
- Orchestra Contracts is an interfaces-only Composer package that defines the shared abstractions underpinning the Orchestra Platform, covering services such as extension discovery, application access, shared memory, authorization bridging, notifier, and widget. It ships no service provider, config, routes, or runtime code, so it provides no capability on its own. Its value is architectural: packages and applications can type-hint stable interfaces instead of concrete orchestra/foundation classes, which keeps them loosely coupled, testable, and swappable.
- How do I install orchestra/contracts in a Laravel application?
- Install it with Composer using a version branch that matches your Laravel major, for example composer require orchestra/contracts:^7.0 for Laravel 9. There is nothing to register or publish afterwards because the package contains only interfaces, with no service provider or configuration file. Before committing, run composer why-not orchestra/contracts against your target Laravel version to confirm the dependency graph resolves cleanly.
- Which Laravel versions does orchestra/contracts support?
- Version branches track Laravel majors, so v7 of the package targets Laravel 9. Check the repository or Packagist for the branch mapping that matches your application before installing. Because the branches follow Laravel releases, a new Laravel major may land before the matching Orchestra branch is available, so plan upgrades around the maintainer's schedule.
- Do I need orchestra/foundation or orchestra/testbench to use orchestra/contracts?
- Technically you can install the package on its own, but it delivers nothing useful in isolation because it is purely abstractions for the Orchestra ecosystem. It only makes sense when you are already building on orchestra/foundation, publishing into the Orchestra ecosystem, or using orchestra/testbench. If you are not on Orchestra, use Illuminate\Contracts, PSR interfaces, and spatie/laravel-package-tools instead.
- Is orchestra/contracts framework-agnostic or Laravel-only?
- Despite the framework-agnostic framing in its overview, the interfaces reference Illuminate\Contracts\Foundation\Application and Illuminate\Support\Collection, so in practice the package is Laravel-only by construction. It does not give you portable, framework-independent ports you could reuse outside Laravel. Treat it as a Laravel abstraction layer for the Orchestra Platform rather than a general-purpose contracts library.
- How do I check whether orchestra/contracts is compatible with my Laravel version?
- Run composer why-not orchestra/contracts against your target Laravel major and review the output. That single command takes minutes and answers the go/no-go question faster than reading documentation. If the constraints conflict, you know immediately whether the package can be adopted or whether you need to delay until a matching branch is released.
- How do I mock or test against orchestra/contracts interfaces?
- Type-hint the Orchestra interfaces in your classes and use Laravel's standard mocking and fake utilities in your tests, since the interfaces are clear and easy to substitute. The package itself ships no signature-assertion suite, so add your own conformance test that asserts your implementations declare the interface and match the expected constructor and method signatures. That test will catch interface drift at CI time instead of at boot in production.
- What are the risks of interface changes or breaking changes in orchestra/contracts?
- The package publishes no formal backward-compatibility policy and ships no signature-assertion tests, so a minor interface change can surface as a fatal type error in your implementing classes at application boot. Mitigate this by pinning the version, adding a conformance test that asserts implements relationships plus constructor and method signatures, and deciding your vendored-fork fallback in advance since the interfaces are MIT licensed. Also assign a named owner for the version pin and the Laravel-major upgrade mapping.
- What are the alternatives to orchestra/contracts for a general Laravel codebase?
- For general Laravel applications, use Illuminate\Contracts, PSR interfaces, and spatie/laravel-package-tools, which have far broader community support and no Orchestra-specific justification burden. If you only want the interface vocabulary from Orchestra, consider vendoring the MIT-licensed interfaces into an App\Contracts namespace. Alternatively, define your own application-facing port and write adapters, taking the Orchestra dependency only after the seam is proven.
- Is orchestra/contracts actively maintained, and can it block my release?
- The repository shows very low star and dependent counts, but those are likely Packagist artifacts because Orchestra's own components necessarily require the package, so treat them as an unknown rather than proof of abandonment. The real maintenance risk is schedule-based: version branches follow Laravel majors, and you absorb the maintainer's timeline for each new release. Avoid placing it on any critical path whose release could be blocked by a lagging branch.