Laravel Add Select Laravel Package

Product Decisions This Supports

• Reporting and dashboard features: enables "computed column" list views — last order date, open ticket count, lifetime value — inside the main Eloquent query rather than an extra query per row.
• Build vs. buy for query helpers: this package represents the "buy" path for a small, recurring engineering need; the alternative is a ~50-line internal trait wrapping Laravel's native selectSub/addSelect.
• Performance trade-offs against roadmap: supports committing to N+1 reduction targets within a sprint instead of scheduling a broader query-layer refactor.
• MVP scoping: lets you promise derived-column features in admin/back-office tools early, since implementation cost is low and reversible.
• Not a strategic differentiator: treat it as plumbing, not a platform bet. It should not influence architecture or vendor strategy.

When to Consider This Package

Consider it when:

• You're on Laravel + Eloquent and repeatedly need subselect columns across admin, reporting, or export features.
• You want the team to standardize on one idiom for derived columns instead of ad-hoc DB::raw strings scattered across repositories.
• The work is internal, low blast-radius, and a stale dependency is tolerable.

Build internally or look elsewhere when:

• Maintenance risk: last release was October 2020 and adoption is thin (32 stars) — likely untested against current Laravel versions. Run a compatibility spike before committing.
• Native coverage: Laravel now ships selectSub() and addSelect(), so much of the value here is ergonomic sugar you can own and evolve yourself.
• Governance: if your org requires maintained dependencies, security review, or LTS support, this won't clear the bar.
• You're not on Eloquent, or you need CTE-heavy reporting where a dedicated query/read-replica layer is the right answer.

How to Pitch It (Stakeholders)

To executives: A free (MIT), small utility that shortens delivery time on reporting-style screens by letting list pages compute derived values in a single query. It's a tactical accelerator, not a platform decision — near-zero cost, risk contained to internal features. Notably, an equivalent helper is buildable in under a day, so frame it as a time-saver rather than a dependency to standardize on.

To engineering: It provides a fluent way to attach subselects to Eloquent queries, cleaning up the "derived column" pattern that otherwise degrades into raw SQL spread across repositories. Given the package's age and low adoption, the pragmatic recommendation is to adopt the pattern: either pin the package after a compatibility spike, or vendor its roughly 50 lines into an owned trait. That gets us the ergonomics without an unmaintained dependency. One decision needed: pick one approach and document it as the team standard.