Larapoke Laravel Package

Getting Started

• Read this release as an EOL notice, not a feature release. v5.1.1 contains no runtime changes — its only content is the announcement that the package is superseded by Laragear/Poke. Plan accordingly.
• New projects: do not install this package. Install laragear/poke instead; it is advertised as feature-equivalent plus current Laravel support.
• Existing projects: first step is a usage audit, not a code change:
  • composer why <vendor/package> and the composer.json constraint.
  • grep -rn for the facade, helper functions, Blade directives, config keys and published asset tags.
  • List every call site — that list is your migration backlog.
• First use case: pick the lowest-risk call site (a read-only lookup, a formatting helper, a single controller action), port it to Poke behind your own wrapper, and ship it. Use that as the template for the rest.
• Look at the Poke README/UPGRADE docs before touching code — the API mapping is the thing you actually need, and it isn't in this release.

Implementation Patterns

Pin before you plan. Immediately constrain the package to the exact current version (e.g. "5.1.1" or "~5.1.1") so a future tag can't change behavior under you while you migrate. Nothing about a superseded package will warn you at install time.

Strangler-fig migration. Introduce a thin application-level adapter (a service class or interface) that wraps every package call. Call sites depend on your abstraction, not on the package's facade or global helpers. Swapping the implementation to Poke then happens in one file instead of dozens.

// app/Support/Poke.php  — your seam
final class Poke
{
    public function handle(string $input): Result
    {
        return Result::fromPackage($input); // the only package call in the app
    }
}

Characterization tests first. Write tests that lock in current behavior before porting anything. Run the same suite against the Poke implementation — that's how you find the behavioral deltas the release notes don't mention.

Migrate per feature, behind config. Don't run both packages side-by-side in the same boot cycle. They are likely to register same-named facades, service-provider bindings or helpers. Use a config flag to switch one feature at a time, and remove the old package's provider when its last consumer is gone.

CI guard. Add a scheduled job running composer outdated / composer audit and, more importantly, a Laravel-upgrade smoke test. Since the successor explicitly claims "latest Laravel support," your framework upgrade path now runs through Poke.

Record the decision. Put a one-paragraph ADR next to the pinned constraint: why this version, what's left to migrate, who owns it. The next developer will otherwise "helpfully" bump it.

Gotchas and Tips

• Doc-only releases are the last ones. v5.1.1 fixes nothing. Any bug you hit from here is yours to patch or work around in your adapter — don't wait for an upstream fix.
• Composer won't tell you it's abandoned. Abandoned/superseded packages resolve normally, and composer require succeeds silently. The only signal is the README. Surface it in your audit tooling.
• Laravel upgrades are the real deadline. The stated differentiator for Poke is current Laravel support. If you're planning a framework bump, migrate the package as part of that work, not after — otherwise you'll be debugging two unrelated breakages at once.
• The 1:1 mapping is usually a lie in these places: config key names, published migration/table names, Blade directives, facade aliases, and event class names. Grep for config('...') and vendor:publish tags before you assume a drop-in swap.
• replace/conflict only at the end. Adding "replace" to composer.json prematurely will mask leftover usages that would otherwise fail loudly. Let the removal of the old dependency be the last commit.
• Debugging tip: diff the two packages' service providers first. That single file tells you what's bound in the container, what's aliased, and what will silently resolve differently.
• Extension points are the sharp edge. Custom drivers, macros, and event listeners are the least likely to have a Poke equivalent. Enumerate them before committing to a migration estimate; they often dominate the effort.
• Don't delete this assessment's context. Keep the supersession note in the repo (README or ADR) so the pinned version reads as deliberate rather than neglected.