Weave Code
Publisher Laravel Package
orchestra/publisher
Orchestra Publisher is a Laravel package for managing and publishing package assets and resources, helping move files into public directories and integrate cleanly with Laravel’s asset publishing workflow.
Orchestra Publisher extends Laravel's native asset publishing into a flexible, multi-destination system. It lets packages ship assets such as JavaScript, CSS and images into the application's public directory while keeping a path memory of what was published, so files can be republished, migrated, or removed reliably.
Built for the Orchestra Platform, it plugs into Laravel's service container and complements the framework's default publisher with pluggable publishing connections.
- Publish package assets to
public/packagesin one call - Pluggable connections: local filesystem and FTP
- Path memory tracks published files for safe re-publishing
- Works with Laravel's
Assetfacade and Orchestra extensions
Frequently asked questions about Publisher
- What is orchestra/publisher used for in Laravel?
- Orchestra Publisher is a Laravel package that extends the framework's native asset publishing into a multi-destination system. It ships package assets such as JavaScript, CSS, and images into the application's public directory and keeps a path memory of published files so they can be republished, migrated, or removed reliably. It is part of the Orchestra Platform ecosystem and is most useful when the host app follows Orchestra's extension conventions. In a conventional Laravel app where destinations are just config_path or public_path, it largely wraps behavior already available through vendor:publish.
- How do I install orchestra/publisher in a Laravel application?
- Require the package with Composer pinned to ^3.5, then register the service provider and the Publisher facade alias in config/app.php because it is not auto-discovered on the 3.x line. After installation, verify method signatures against the exact tag you pinned since names changed between 2.x and 3.x. A quick smoke test is running php artisan vendor:publish --list to confirm the provider booted.
- Does orchestra/publisher support Laravel 9, 10, or 11?
- The public release line tops out at Laravel 5.5, which reached end of life in 2019. There is no forward-compatibility evidence for modern Laravel versions, and the changelog is a single line. Treat any upgrade to a current framework as a fork-or-patch event that you own. Verify booting and publishing on your exact Laravel version rather than inferring support from the changelog.
- How do I publish package assets to public/packages with Orchestra Publisher?
- Use the Publisher API in src/Publisher.php, typically chaining extensions, publishes, and publish, or queue for batched work. A common call publishes package assets into public/packages. Because publishing goes through Laravel's vendor:publish registry, the registered publishes are visible with php artisan vendor:publish --list. Verify method signatures against your pinned tag before copying examples from older documentation or blog posts.
- What are publishing connections in orchestra/publisher and can I publish via FTP?
- Publisher supports pluggable publishing connections, with local filesystem and FTP drivers available. Connections let you target different destinations without rewriting publish logic. The package plugs into Laravel's service container and complements the framework's default publisher. Check the tag you pin for the exact connection configuration keys and behavior.
- How does path memory work in Orchestra Publisher?
- Path memory records what was published so the package can republish, migrate, or remove those files reliably. It helps avoid orphaned assets and makes repeat publishing more deterministic. Because the publisher accumulates queued state, long-lived workers, Octane, or two sequential install flows may require an explicit flush between batches. Plan for that flush in any programmatic publishing flow.
- How do I stop Orchestra Publisher from overwriting edited config files with force?
- Laravel publish semantics skip existing files unless forced, so a blind force can silently destroy local edits to operator-editable config. Split resource groups by ownership, separating code-owned files from operator-editable files, rather than by convenience. Namespace every tag, for example acme-reports-config, so two packages registering config do not interleave silently. Then force only the code-owned group.
- Is orchestra/publisher maintained and safe to use in production?
- The dominant risk is lifecycle, not code quality: the release line stops at Laravel 5.5, there are zero dependents, and no security disclosure posture is on file. Any framework upgrade becomes a fork-or-patch event that your team owns. It can run in production where the Orchestra extension model is already in use, but confine calls behind your own abstraction so replacement costs one class. Also govern force overwrites and namespaced tags carefully.
- How do I test that Orchestra Publisher is registered and publishing correctly?
- Register the provider and facade alias, then run php artisan vendor:publish --list to confirm the provider booted and the publishes are registered. This is a fast smoke test because the package publishes only through Laravel's framework registry. For programmatic flows, assert that the expected files land in public/packages and that path memory updates. Include a test for flush between batches if you publish in long-lived processes.
- What are alternatives to orchestra/publisher for Laravel asset publishing?
- If all your destinations are conventional config_path or public_path, Laravel's built-in vendor:publish plus a small internal helper is simpler. Laravel Packager or custom publish service providers can also cover package asset shipping. Orchestra Publisher earns its keep only when you need Orchestra-style extension-aware path resolution or pluggable local and FTP connections. Keep it behind an interface if you might swap it later.
Weaver
How can I help you explore Laravel packages today?