Laravel Sub Query Laravel Package

Getting Started

• Upgrade to v1.9.9 normally. This release is additive: it adds whereCurrentYear, whereCurrentMonth, and whereCurrentDay; no breaking changes are indicated.
• First place to look is the package source/docs for the exact signatures. Confirm whether these methods accept a column argument, e.g. whereCurrentYear('created_at'), and whether they are query-builder macros or Eloquent scopes.
• Smoke-test in Tinker or a test:

Order::whereCurrentYear('placed_at')->count();
Order::whereCurrentMonth('placed_at')->count();
Order::whereCurrentDay('placed_at')->count();

• First practical use case: add “This year / This month / Today” filters to an admin list or dashboard metric without hand-rolling Carbon boundary logic.

Implementation Patterns

Use the new methods as convenience date scopes on Eloquent queries, always passing the business-relevant timestamp column explicitly:

$revenueThisMonth = Order::query()
    ->whereCurrentMonth('paid_at')
    ->where('status', 'paid')
    ->sum('total');

Build dashboard cards or report filters around them:

$query = Post::query()->where('is_published', true);

if ($range === 'today') {
    $query->whereCurrentDay('published_at');
} elseif ($range === 'month') {
    $query->whereCurrentMonth('published_at');
} elseif ($range === 'year') {
    $query->whereCurrentYear('published_at');
}

$posts = $query->latest('published_at')->paginate();

Encapsulate repeated business meaning in model scopes rather than scattering the raw methods:

public function scopePublishedThisYear($query)
{
    return $query->whereCurrentYear('published_at');
}

Use them in scheduled commands and reports where “current” means the calendar year/month/day at execution time:

$dailySignups = User::whereCurrentDay('created_at')->count();

For tests, freeze time and verify boundaries:

Carbon::setTestNow('2025-03-01 00:00:00');

$this->assertSame(0, Order::whereCurrentMonth('placed_at')->count());

Gotchas and Tips

• Timezone boundaries matter. “Current day/month/year” can differ between the app timezone, database session timezone, and end-user timezone. Confirm whether the package evaluates current time in PHP or delegates to the database, and test around midnight, month-end, and year-end.
• Inspect generated SQL. If the methods compile to functions like YEAR(column) = ?, MONTH(column) = ?, or DAY(column) = ?, they may prevent normal index usage on large tables. Prefer explicit whereBetween ranges for high-volume queries when performance matters.
• whereCurrentDay means calendar day, not “last 24 hours.” If you need rolling windows, use explicit now()->subDay() boundaries instead.
• Use the correct date column. created_at is rarely the right business column for reporting; use paid_at, published_at, shipped_at, etc.
• Confirm null behavior. Date filters generally exclude null values; verify this matches report expectations.
• Wrap in scopes for consistency. If several teams use these filters, centralize them in model scopes so timezone and column choices are consistent.
• Run date-filter tests after upgrading. The change is low-risk and additive, but boundary-sensitive logic deserves explicit tests.
• If the methods do not appear, clear cached package/config state and confirm Laravel auto-discovery or the service provider is registered as required by the package.