Weave Code
Support Laravel Package
orchestra/support
Orchestra Support provides foundational helpers for Laravel applications and Orchestra Platform extensions, including base service providers, memory limit utilities, string and array helpers, and testing conveniences that streamline package development.
Orchestra Support is the shared utility layer for the Orchestra Platform and its Laravel packages. It supplies reusable helpers, base classes, and contracts that simplify building consistent extensions and admin components.
- Reusable helper utilities for strings and common Laravel tasks
- Base service provider and package bootstrapping support
- Shared contracts and facades across Orchestra packages
- Lightweight memory and runtime helpers for extension workflows
Frequently asked questions about Support
- What is orchestra/support used for?
- Orchestra Support is the shared utility layer for the Orchestra Platform and its Laravel packages. It provides reusable string and array helpers, base service provider and package bootstrapping support, shared contracts and facades, in-memory registry and memory limit utilities, and testing conveniences. Its main value is avoiding boilerplate and enforcing conventions across a portfolio of Laravel packages, so it is internal scaffolding rather than customer-facing application capability. It has no database footprint and integrates through Composer only.
- How do I install orchestra/support in a Laravel application?
- Installation is a single Composer require of orchestra/support, with no database migrations or publish steps required. In many projects the package is already present transitively, most commonly through orchestra/testbench, so run composer why orchestra/support before adding it explicitly. Confirm the PHP and Laravel floor first: Laravel 9 needs PHP 8.0+, Laravel 10 needs 8.1, and Laravel 11 needs 8.2.
- Which Laravel and PHP versions does orchestra/support support?
- Version 7.0.0 of orchestra/support raised the minimum framework requirement to Laravel 9 and above, so older Laravel releases need an earlier package release. Match PHP to your Laravel version: PHP 8.0+ for Laravel 9, 8.1 for Laravel 10, and 8.2 for Laravel 11. On Laravel 9+ the install is essentially drop-in; on Laravel 8 the real work is a framework migration, not a package decision.
- Is orchestra/support already installed through orchestra/testbench?
- Very often yes. Orchestra Testbench, the standard tool for testing Laravel packages, pulls orchestra/support in transitively, so many applications inherit it as a development dependency without ever choosing it. Run composer why orchestra/support to see who requires it. If nothing in your code calls its API, removing the explicit dependency may be the better decision than sequencing an upgrade.
- What helpers and utilities does orchestra/support provide?
- It ships reusable string and array helpers, collection extensions, traits, a message collection, an in-memory registry, and memory limit and runtime helpers aimed at extension workflows. It also includes base service provider classes, shared contracts, and facades used across Orchestra packages. These utilities are designed to keep multiple Laravel packages consistent rather than to add features to a single application.
- Can I use orchestra/support with Laravel Octane or queue workers?
- Use it carefully. The in-memory registry is effectively long-lived state, so as a singleton it can leak data between requests in Octane or between jobs in queue workers. Reset it in a terminate hook or scope it per request, and test the behaviour under a long-running worker before shipping. This is the most likely source of a production incident with this package.
- What changed between orchestra/support v6 and v7?
- The documented change for v7.0.0 is raising the framework floor to Laravel 9 and above, but a one-line changelog for a major release means you should treat it as a contract reset. Read the v6 to v7 diff directly for renamed classes, changed method signatures, and facade alias changes before upgrading. Do not rely on the changelog alone when planning the migration.
- Does orchestra/support conflict with Illuminate\Support?
- It does not technically conflict, but it introduces a second vocabulary alongside Illuminate\Support. Two sets of Str, Arr, and service provider conventions in one codebase is a recurring source of confusion for developers and reviewers. Be explicit in code reviews about which helper set a given file uses, and avoid mixing them within the same class where possible.
- Is orchestra/support safe to depend on in production?
- Treat it as a niche ecosystem dependency rather than a vendor-backed one. It has limited public adoption metrics, a small maintainer base, and no vendor SLA, and its Laravel support ceiling is tied to the Orchestra Platform roadmap. It is a reasonable fit for internal tooling and multi-package scaffolding, but a poor fit for customer-critical paths where an unmaintained foundational dependency is an unacceptable risk.
- When should I avoid orchestra/support, and what are the alternatives?
- Skip it for single-package applications, for projects still on Laravel 8 without a funded framework migration, and for anything on a customer-critical path. The Laravel framework's own Illuminate\Support helpers and your application's internal base classes cover most of the same ground. If you adopt it, consider an internal facade as a single-file replacement seam so a future rename or abandonment is a one-file fix rather than a refactor.
Weaver
How can I help you explore Laravel packages today?