Publisher Laravel Package

Product Decisions This Supports

• Build-vs-buy on extension plumbing. If the roadmap includes third-party extensions, add-on modules, partner distribution, or a reseller model, someone must answer: how do a module's config, views, migrations, translations, and assets land in the host app? The default answer is hand-rolled vendor:publish orchestration duplicated in every extension — inconsistently tagged, inconsistently idempotent. Orchestra Publisher is a candidate buy for that layer: a chainable publisher that registers and releases resource groups in a single call.
• Ecosystem and integration strategy. A unified publishing API is an onboarding tax reducer for external developers. Lowering boilerplate for extension authors is a direct lever on how many partners can ship a working module in a day versus a sprint — a legitimate input when weighing an "open extension marketplace" against "curated first-party modules only."
• Install/upgrade UX as a product surface. Tag-scoped publishing and per-resource force/overwrite control are the primitives behind "Install module," "Upgrade module," and "repair a half-published install" flows. If those are on the roadmap as CLI or admin features, this component either supplies them or must be replicated.
• White-label / multi-instance distribution. Extension-aware path resolution matters when the same package ships into differently configured deployments (per-tenant asset paths, per-brand config sets). Whether that resolution logic is ours or a dependency's is a real architecture call with product consequences.
• Support-cost modelling. Mis-published assets and stale config after upgrade are a recurring, low-severity, high-volume ticket class. A standardised publisher with explicit overwrite semantics is a plausible reducer — but treat that as a hypothesis to instrument, not a forecast.
• Roadmap scoping — what it should not drive. This is a Laravel-internals convenience layer, not a platform decision. It should never be the reason to choose a modular architecture. Per available signals (v3.5.0 is a single line — "Update support to Laravel Framework 5.5"; zero dependents; low overall package score), it carries no adoption or momentum evidence usable in a roadmap review.

When to Consider This Package

Consider it when:

• You are already inside, or deliberately aligning with, Orchestra Platform — this is a component of that stack, and its value is highest where the surrounding conventions already exist.
• You have a modular/extension architecture whose packages ship multiple resource kinds (assets + config + migrations + translations + views) and you want one declaration point rather than five bespoke copy steps.
• Your install/upgrade flows need programmatic publishing, triggered from an artisan command, an admin "install extension" action, a seeder, or a CI step — not just a human typing vendor:publish.
• You specifically need tag-scoped publishing (release only what changed) and per-resource force overwrite (idempotent upgrades without clobbering operator edits).
• Your framework version is a known, pinned match to what the package actually declares in composer.json — not merely what a changelog line implies.

Look elsewhere or hold when:

• You are on a modern Laravel line. The only release evidence on file tops out at Laravel 5.5, end-of-life since 2019. Do not infer forward compatibility. If the maintainer has not published support for your target version, treat it as unmaintained for your purposes.
• You only need one-off publishing. A vendor:publish call in a deploy script or a small Composer script does not justify a dependency, a support relationship, and a version constraint sitting in your framework-upgrade path.
• You need adoption evidence. Zero dependents plus a maintenance-mode changelog is a weak bet for anything load-bearing. If extensions are strategic, the publisher should not be a single point of failure for partner onboarding.
• Your requirements exceed file copying — inter-module dependency resolution, transactional installs, rollback, versioned cross-tenant migrations. This package publishes resources; it does not orchestrate lifecycle.
• You need an evidenced security/disclosure posture. Nothing here demonstrates one.

Adoption gate (run before any commitment): a time-boxed spike that pins the exact tag, verifies boot under your shipped Laravel version, exercises one full publish set in staging, and confirms the queue reset method (flush() or equivalent) against src/Publisher.php. If that spike fails, the fallback is a ~50-line internal helper — cheap enough that the decision is reversible.

How to Pitch It (Stakeholders)

For executives: This is small infrastructure, not a feature. It standardises how add-on modules deliver their files into our product — the difference between "a partner ships a working module in a day" and "every partner reinvents install plumbing." The business case is ecosystem velocity and reduced install-related support load: both real, neither proven here. The honest caveats: it is a component of Orchestra Platform; it shows no adoption signal (zero dependents, low package score); and its only documented release targets Laravel 5.5, an end-of-life framework line. Recommendation: evaluate, do not commit. Fund a short, time-boxed spike to answer one question — does it work on the Laravel version we actually ship? — and keep the module-publishing API as our abstraction regardless, so a future dependency swap costs days rather than a re-architecture.

For engineering: It provides a fluent, chainable publisher that queues assets, config, migrations, translations, and views and executes them in one call, with force/overwrite per resource, tag filtering, and extension-aware path resolution — wrapping vendor:publish semantics in a composable object instead of console strings and ad-hoc File::copyDirectory. Before adoption: (1) confirm the supported Laravel range in the pinned tag's composer.json, not the changelog; (2) note it is not auto-discovered on 3.x — you register the provider and Publisher facade alias manually; (3) type-hint the contract in src/Contracts/ rather than the concrete class, since method names shifted across the 2.x → 3.x line; (4) keep every publish declaration behind a single PublishManifest class so the dependency is confined to one file; (5) treat the publisher as a singleton with mutable state — flush between batches and keep it off the request path entirely (deploy/provisioning only). Publishing migrations does not run them, so any install command must sequence migrate --path explicitly. Budget for a fork: with one-line changelogs and no dependents, we own the version bumps.