Weave Code
Optimize Laravel Package
orchestra/optimize
Orchestra Optimize is a Laravel package from the Orchestra Platform ecosystem that provides Artisan commands and helpers for caching configuration, routes, views, and compiled classes. It helps speed up production deployments and reduce bootstrap overhead.
Optimize Component for Orchestra Platform
Frequently asked questions about Optimize
- What does orchestra/optimize actually do?
- It is a deploy-time CLI helper from the Orchestra Platform ecosystem that registers Artisan commands to cache Laravel configuration, routes, views and compiled classes. It ships a service provider that adds one or two commands to the console kernel, sequences Laravel's native cache operations, and exits. There is no middleware, no runtime request path, no database surface and no configuration of consequence, so it is best thought of as a standardized deploy step rather than an application-layer library.
- Which Laravel versions does orchestra/optimize support?
- The latest 3.3 release targets Laravel 5.3, while the 3.2.x line covers Laravel 5.1 and 5.2. Laravel 5.3 has been end-of-life since 2017, so there is no support for 5.4 or any modern release. For Laravel 5.4 and later you should use the framework's built-in optimize and optimize:clear commands instead.
- How do I install orchestra/optimize in a Laravel 5.3 application?
- Run composer require "orchestra/optimize:^3.3" and commit composer.lock in the same change. Laravel 5.3 predates package auto-discovery, so you must add the package's OptimizeServiceProvider::class to the providers array in config/app.php manually. There are no migrations, no assets to publish and no environment configuration to negotiate.
- Does orchestra/optimize conflict with Laravel's built-in optimize command?
- It can. The package registers a command named optimize, and if the framework or another package registers a command with the same name, resolution depends on kernel registration order. That can silently switch which class executes mid-project, which is a genuinely nasty surprise during an incident. Run php artisan help optimize to confirm which class is actually handling the command in your app.
- Is orchestra/optimize still maintained?
- No. The most recent release is a Laravel 5.3 compatibility bump, there are zero dependents, no visible community and no support channel. Nothing here receives security patches, so maintenance silence should be treated as a no. If you are on anything newer than 5.3, the framework's own optimize command is maintained by the core team.
- Should I use orchestra/optimize or just run artisan commands in my deploy script?
- For most teams a deploy script is better: a few lines running php artisan config:cache, route:cache and view:cache with matching clears is transparent and carries no dependency lifecycle cost. The package's only real architectural value is standardizing that deploy step across environments. On Laravel 5.4 and later the native optimize command already covers this, making the dependency redundant.
- What are the risks of caching config, routes and views in production?
- These are inherited framework behaviours rather than package bugs, but the package makes triggering them a one-command operation. config:cache breaks any env() call made outside config/*.php, route:cache fails hard on closure-based routes, and view:clear can leave storage/framework/views unwritable and return a 500 on every page. Run the full cache and clear cycle in staging before using it in production.
- Does orchestra/optimize work on Laravel 5.4, 5.5 or newer?
- No. The package stops at the Laravel 5.3 compatibility bump, and every Laravel release from 5.4 onward ships optimize and optimize:clear in core, maintained by the core team. On 5.4+ this package is strictly negative value because it adds a dependency with no capability you do not already have. Upgrade the framework rather than adopting it.
- How do I remove orchestra/optimize from a project?
- Run composer remove orchestra/optimize and delete the OptimizeServiceProvider line from config/app.php. Because the package has no migrations, publishable assets or meaningful configuration, removal is quick. Replace it instead of simply deleting it by keeping the equivalent artisan cache commands in your deploy pipeline.
- What is the "compiles list" mentioned in the orchestra/optimize 3.3.0 release notes?
- It is undefined in the documentation, which is a real scope ambiguity rather than a documentation nit. The package description only claims config, route and view cache management, but compiles list could plausibly touch Blade compilation output, a manifest, or nothing user-visible at all. Confirm what it actually changes at runtime before depending on it in a deployment.
Weaver
How can I help you explore Laravel packages today?