Lara Like Laravel Package

Getting Started

The 1.0.4 release renames the package's primary user-resolution method: loggedInUser() → getLoggedInUserForLaraLike(). That is the one thing to internalise before touching anything else — every other step below is downstream of it.

1. Pin the version explicitly. Since 1.0.4 contains a breaking rename rather than a deprecated alias, constrain Composer rather than floating:

   composer require vendor/laralike:"^1.0.4"
   

   If you are not ready to migrate call sites, stay on 1.0.3 deliberately ("1.0.3" or "~1.0.3") rather than letting a composer update pull the rename in silently.

2. Look first at the service provider and the facade/helper source. Open vendor/vendor/laralike/src/ and find where getLoggedInUserForLaraLike() is declared, plus whatever facade or global helper proxies it. That method is the day-to-day entry point for the whole package; everything else (config, provider bindings) exists to support it.

3. Confirm the binding resolves. Run a one-liner before writing real code:

   php artisan tinker --execute="dump(app(\Vendor\LaraLike\LaraLike::class)->getLoggedInUserForLaraLike());"
   

4. First real use case: resolving the authenticated user from a context where you do not want to reach into a framework-specific guard — a Blade partial, a queued job that carries a user id, a shared trait, or a package-agnostic service class.

   use Vendor\LaraLike\Facades\LaraLike;
   
   $user = LaraLike::getLoggedInUserForLaraLike();
   
   if ($user === null) {
       // guest context
   }
   

   Note the method name says get, not check — treat it as a nullable resolver and always branch on null rather than assuming a user exists.

Implementation Patterns

Wrap the call once, in your own code. The rename is the strongest possible argument against calling a vendor method directly from twenty places. Introduce a single seam:

// app/Support/CurrentUser.php
namespace App\Support;

use Vendor\LaraLike\Facades\LaraLike;

class CurrentUser
{
    public static function resolve(): ?object
    {
        return LaraLike::getLoggedInUserForLaraLike();
    }
}

Every subsequent rename upstream costs you one line instead of a codebase-wide sweep. Inject this class rather than calling the facade statically where you can — it makes tests trivial and keeps the dependency graph honest.

Blade usage. Resolve once in the view and reuse, rather than calling the facade repeatedly in a loop:

@php($currentUser = \App\Support\CurrentUser::resolve())

@if($currentUser)
    <span>{{ $currentUser->name }}</span>
@else
    <a href="{{ route('login') }}">Sign in</a>
@endif

If your views contain many legacy laralike()->loggedInUser() calls, a Blade component or view composer that shares $currentUser globally is a cheaper migration than editing each template.

Middleware and policies. Use the resolver as a cheap pre-check in middleware (abort_unless(CurrentUser::resolve(), 401)), but keep authorisation logic in policies and gates — this package answers who, not may they. Do not let the helper become an authorisation bypass.

Testing. Because the method is a static facade call under the hood, bind a fake in tests so you are not depending on session state:

$this->app->instance(\Vendor\LaraLike\LaraLike::class, new class {
    public function getLoggedInUserForLaraLike() { return User::factory()->make(['id' => 7]); }
});

Alternatively, drive it through the real path with $this->actingAs($user) — preferable when you want to verify the package's guard resolution actually works against your auth config. Prefer actingAs for integration tests, the fake for unit tests that only care about downstream behaviour.

Queued jobs and console commands. There is no logged-in user in a worker or a artisan invocation. Guard the call:

$user = app()->runningInConsole() ? null : \App\Support\CurrentUser::resolve();

Or better, capture the user id at dispatch time and pass it explicitly into the job — never resolve the "current" user inside a queued job and expect it to match the dispatcher.

Multi-guard setups. If your app has more than one guard (admin + customer), verify what the package resolves against. If it only understands the default guard, do not use it on admin routes — reach for Auth::guard('admin')->user() there and keep this package confined to the default guard's surface.

Gotchas and Tips

The rename is silent and breaking. loggedInUser() is presumably gone entirely — there is no mention of a deprecation shim or __call fallback in the release note. Any surviving call will surface as BadMethodCallException: Method ...::loggedInUser does not exist (Laravel's __callStatic/facade path) or a PHP Error: Call to undefined method on a direct instance call. Neither is subtle at runtime, but both are invisible until the code path executes — so a grep is mandatory, not optional.

Sweep every surface, not just app/:

grep -rn --include='*.php' --include='*.blade.php' "loggedInUser" app/ resources/ routes/ config/ database/ tests/ bootstrap/

Pay particular attention to:

• tests/ — a mocked expectation like ->shouldReceive('loggedInUser') will pass or fail misleadingly depending on the mock type; a Mockery expectation on a method that no longer exists will error, but a hand-rolled stub class may silently keep working and hide the problem.
• config/ — if the package name is referenced in a serialised closure or string callback.
• Custom service classes extending or decorating the package's class — an override of loggedInUser() will now not override anything, so your customisation is silently bypassed. This is the worst failure mode of the whole migration: no error, just wrong behaviour.

Clear the compiled caches. Blade caches compiled templates in storage/framework/views/; Laravel caches config and routes. After editing templates or config:

php artisan view:clear && php artisan config:clear && php artisan route:clear

A stale compiled Blade view will keep executing the old method name after you have "fixed" the source template, which is a genuinely confusing five minutes to debug.

Regenerate IDE helper stubs. If you use _ide_helper.php / _ide_helper_models.php, the facade docblock listing loggedInUser() is stale. Delete and regenerate, otherwise static analysis and IDE completion will keep suggesting a method that no longer exists and you will reintroduce the bug while typing.

Check transitive dependants. Any other package in your composer.json that depends on this one and calls the old name will break on upgrade. Run composer why vendor/laralike and composer update --dry-run to see what moves; consider composer prohibits vendor/laralike 1.0.4 to identify blockers before committing to the bump.

Version-lock your CI image and lockfile. composer.lock should be committed and the CI install should use composer install --no-dev --prefer-dist (not update). A floating constraint plus a CI runner doing composer update is how a patch-level release takes down a deploy.

Extension point for partial migrations. If you cannot update everything at once, add a transitional alias in your own code rather than patching vendor/:

class LaraLikeCompat extends \Vendor\LaraLike\LaraLike
{
    public function loggedInUser()
    {
        return $this->getLoggedInUserForLaraLike();
    }
}

Bind it in a service provider and keep the constraint pinned to 1.0.4. vendor/ edits are lost on the next install and are not a migration strategy.

Read the changelog for intent. "To avoid conflicts" suggests the old name collided with a global helper or another package's macro. If you were relying on loggedInUser() resolving to your own helper in some contexts, that ambiguity is now resolved in the package's favour — audit any globally registered helper functions with that name and consider renaming yours too.