Sidekick Laravel Package

Product Decisions This Supports

• Build vs. buy for internal package plumbing: Use orchestra/sidekick as a “buy/consume” decision when we maintain Laravel packages and repeatedly need small utilities for Eloquent model diffing/state, package paths, version comparison, environment checks, filesystem naming, container resolution hooks, and Testbench-aware CLI detection. The buy case is developer time saved and consistency, not customer-facing capability.
• Standardize internal package scaffolding: Consider adopting it inside an internal Laravel package template so package teams share one set of helpers instead of duplicating 5–30 line utilities across repositories.
• Roadmap impact: Treat this as engineering enablement, not a product roadmap item. It should not displace customer-facing features; its value is reduced glue code, faster package maintenance, and more consistent test setup.
• Use cases to prioritize: Laravel package development, Testbench-based integration test suites, model change tracking/auditing helpers, package version/path resolution, console prompt configuration, and compatibility polyfills across Laravel versions.
• Adoption posture: Run a contained pilot in one package or the internal package template before mandating it. Measure duplicate helper removal, package maintenance time, and test-workflow friction.
• Risk decision: The package is MIT-licensed, Composer-only, and has no service provider/config/migration surface, so integration cost is low. But the niche is narrow, listed dependents are zero, and some APIs are marked @internal; pin versions and avoid spreading direct calls across critical code without a thin internal wrapper.

When to Consider This Package

Consider it when:

• We publish or maintain Laravel packages, not just consume them in product applications.
• We use Orchestra Testbench or similar package-testing workflows and want helpers that recognize Testbench CLI contexts.
• We repeatedly implement Eloquent helpers such as previous attributes, model state, model diffing, or model reconstruction from data.
• We need small framework-native utilities for package paths, version comparison, environment handling, filesystem class-name-to-filename conversion, or deferred container resolution.
• We want a tiny, Composer-only, MIT-licensed dependency with no application bootstrap requirements.
• We value release discipline and cross-version support, including polyfills for older Laravel versions and forward-looking PHPUnit/Laravel compatibility work.

Look elsewhere when:

• We only build product applications and do not maintain Laravel packages. In that case the helpers are marginal conveniences rather than a strategic dependency.
• We need broad application infrastructure such as admin panels, authentication, media handling, queues, or domain workflow tooling.
• The needed behavior is a one-off or trivially implemented internally, and adding a dependency creates more governance cost than value.
• We require a large dependents base, multiple maintainers, commercial support, or a long-term public API guarantee. The package’s score suggests ecosystem health, but its opportunity score reflects a deliberately narrow package-author niche.
• We would depend on @internal classes or traits as part of a critical public contract. Prefer stable helper functions or wrap usage behind our own abstraction.

How to Pitch It (Stakeholders)

Executive summary: orchestra/sidekick is a low-cost developer-productivity dependency for teams that ship Laravel packages. It is not customer-facing infrastructure and does not add runtime services, configuration, or migrations. It packages common internal helpers used by the Orchestra ecosystem—model diff/state utilities, environment and path helpers, package version comparison, filesystem helpers, and Testbench-aware checks—so engineers can avoid reimplementing boilerplate.

Engineering summary: Adopt it selectively where it removes repeated package-author glue code and improves consistency across internal packages. It is Composer-only, MIT-licensed, framework-native, and test-friendly, with active maintenance releases and compatibility polyfills. The main caveats are narrow scope, limited listed dependents, and some internal-marked APIs; pin versions and isolate critical usage behind our own helpers if needed.

Recommendation: Approve a small pilot in one maintained Laravel package or the internal package template. Success criteria: fewer duplicated helper functions, reduced package-maintenance overhead, no added integration friction, and stable test-suite behavior. Do not position it as an application framework dependency or a roadmap feature; position it as a low-risk engineering enablement tool with a clear “packages-only” adoption boundary.