Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message
Support Core

Support Core Laravel Package

orchestra/support-core

Core support utilities for the Orchestra Platform, providing shared helpers, service providers, and foundational traits that other Orchestra packages build on. Lightweight, framework-agnostic glue for Laravel applications that need a consistent base for extension development.

View on GitHub
Deep Wiki
Context7

Orchestra Support Core provides the foundational support layer for Laravel applications and Orchestra Platform extensions. It packages reusable service provider utilities, helpers, and conventions that keep package bootstrapping consistent and reduce boilerplate across the ecosystem.

  • Lightweight service providers and bootstrapping helpers for Laravel packages.
  • Shared utility classes and helpers for common support tasks.
  • Extension-friendly conventions for Orchestra Platform components.
  • Small, framework-aligned API that composes with other Orchestra packages.
Frequently asked questions about Support Core
What is orchestra/support-core used for?
Orchestra Support Core is a foundation library that packages reusable service provider base classes, utility helpers, and extension conventions for Laravel applications and Orchestra Platform components. It is not a feature package; it is a convention layer that reduces boilerplate when bootstrapping packages. Most developers use it to avoid hand-rolling register(), boot(), and mergeConfigFrom() logic in every package. It is aimed at Orchestra Platform extension work and multi-codebase Laravel estates rather than single applications.
How do I install orchestra/support-core?
Install it with Composer using composer require orchestra/support-core:^7.0. In many real projects it already arrives transitively through orchestra/testbench or another Orchestra component, so run composer why orchestra/support-core first to confirm whether you are adding a direct or indirect dependency. No manual provider registration is required for the base classes, since you typically extend them rather than boot them directly.
Which Laravel and PHP versions does orchestra/support-core support?
Version 7.0.0 states Laravel Framework v9+ as its requirement, which transitively implies PHP 8.0 or newer. That wording is ambiguous between Laravel 9.x only and a multi-major range such as 9 through 12, so check the actual illuminate/* and php constraints in the installed composer.json. Do not assume forward compatibility with the next Laravel major until you have verified the constraint range yourself.
Does orchestra/support-core work with Laravel 12 or future Laravel versions?
The release note only says Laravel v9+, which is not an automatic forward-compatibility guarantee. Whether Laravel 12 works depends entirely on whether the illuminate/* constraint is a multi-major range or pinned to ^9.0, which would dead-end at Laravel 10. Read the installed composer.json and test against your target framework version before committing to an upgrade path.
What is the difference between orchestra/support-core and illuminate/support?
There is significant overlap: illuminate/support already provides Str, Arr, and Htmlable helpers that cover many of the same tasks. Orchestra Support Core adds service provider base classes, extension contracts, and Orchestra-specific conventions on top of that baseline. For a single Laravel service with no Orchestra involvement, the overlap makes it a net-negative addition. Its value appears when you need one shared convention layer across several packages or codebases.
Does orchestra/support-core autoload global helper functions that could conflict?
Helpers autoloaded through Composer files can fatal on redeclaration if your application defines a function with the same name. Check the package's composer.json autoload files section and inventory which function names become reserved in your global namespace. This matters most on rendering paths, where string and HTML helper behavior is also security-relevant if escaping semantics differ. Wrapping helper calls in internal adapters limits both collision and replacement risk.
Does orchestra/support-core auto-register any service providers?
The package is designed to stay largely inert until you extend its base classes or use its traits and helpers. You should still verify whether it declares anything under extra.laravel.providers in composer.json, since that would cause automatic registration. If no providers are auto-registered, adopting it is a low-risk, incremental decision. Confirm this in the installed package rather than relying on the readme.
Is orchestra/support-core maintained and safe for production use?
It is a single-maintainer ecosystem project with no published support or deprecation policy, no vendor support tier, and no listed dependents, so treat it as community tooling. That is acceptable for internal tooling and package scaffolding but materially different on a customer-facing request path. If it becomes load-bearing through transitivity, you are accepting unmaintained-dependency risk. Run composer why orchestra/support-core to see whether you actually depend on it directly or indirectly.
Should I use orchestra/support-core in a single Laravel application or only for Orchestra Platform extensions?
It is fundamentally intended for Orchestra Platform extension development and for multi-codebase Laravel estates that show drift in providers, helpers, or extension interfaces. In a single service, the overlap with illuminate/support usually outweighs the benefit, so it is generally not worth adding. If you do adopt it, define a usage policy up front: whether application code may call its helpers directly or only through internal adapters. That policy determines your eventual exit cost.
What should I check before upgrading orchestra/support-core from v6 to v7?
Assume breaking changes beyond the stated framework support bump, because major releases commonly raise PHP minimums, tighten illuminate/* constraints, and reshape helper signatures. Diff src/ between your locked v6 and v7 rather than trusting the release note. Also grep your codebase with grep -rn 'Orchestra\Support' app/ packages/ to measure exit cost in call sites. Test the upgrade in a branch against your target Laravel version before merging.
Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
middlewares/firewall
qubiqx/montapacking
nyoncode/laravel-package-console
pnscripts/filament-broadquill-lite
pnscripts/laravel-sentfold-lite
vleap/mx-sdk-laravel-internal
twidpay/utils
htetmyathlaing/scout-elasticsearch-driver
artisan-toolbox/front-awesome
ls/client-assistant
users-au/laravel-client
cgv/localized-resource
noith/settings
kda/laravel-package
kda/filament-dynamic-navigation
bypersoft/signbox
pairus/product-data
fayne/laravel-filament-cms-core
nodisrupt/laravel-agent
sierratecnologia/media-manager