Laravel Guesser Helpers Laravel Package

Getting Started

mPhpMaster/laravel-guesser-helpers is a small utility package that centralises the "guess the convention" logic Laravel apps tend to scatter around: resolving a model class from a table/route string, inferring table names, relation names, foreign keys, and similar naming conventions. Version 1.0.0 is the first tagged release, so treat the API as young and pin it explicitly.

Minimal steps:

composer require mphpmaster/laravel-guesser-helpers:1.0.0

• The package follows the usual mPhpMaster layout: a service provider with package auto-discovery, and helper functions or a facade registered globally. After install, confirm they are loaded before writing code against them:

php artisan tinker
>>> function_exists('guess_model') // or whatever the README documents

• If auto-discovery is not declared in the package's composer.json, register the provider manually in bootstrap/providers.php (Laravel 11+) or config/app.php.
• Look first at the package src/ directory and README — 1.0.0 shipped with no meaningful release notes beyond a changelog link, so the source is the authoritative reference for exact function names and signatures.
• Check whether a config file is publishable (php artisan vendor:publish --tag=guesser-helpers) and whether it exposes a namespace/prefix mapping you should set for your app.

First use case: a generic admin/resource controller where you currently hardcode model class strings per resource. Replace the hardcoded map with a guesser call keyed off the route segment, then override only the exceptions.

Route::resource('blog-posts', PostController::class);

class PostController extends Controller
{
    public function index(string $resource)
    {
        $model = guess_model($resource); // 'blog-posts' -> App\Models\BlogPost

        return $model::paginate();
    }
}

Implementation Patterns

Convention-first, config-second resolution. The productive pattern is to let the guesser handle the 80% that follow Laravel conventions and keep a thin override map for the rest. Wrap the package rather than calling it inline everywhere:

final class ResourceResolver
{
    public function model(string $resource): string
    {
        return config("resources.overrides.$resource")
            ?? guess_model($resource);
    }
}

This keeps a single seam for testing and lets you swap the package later without touching controllers.

Generic CRUD and scaffolding. Guessers shine in code that is deliberately model-agnostic: base resource controllers, generic DataTables/ApiResource endpoints, artisan commands that generate files from a table name, and stub-based scaffolding. In each case the guesser removes the need for a hand-maintained registry that drifts as the app grows.

Validation rules. Form requests frequently need the table name for unique/exists rules where the model is dynamic. Resolving it through the guesser keeps the rule consistent with the model's actual table, including when a model overrides $table.

$table = guess_table(Model::class);
$rules = ['email' => ["unique:$table,email"]];

Route model binding fallbacks. For catch-all or CMS-style routes where the segment is user-defined, use the guesser to attempt a model resolution and then fall back to a 404 or an explicit map. Always validate the guessed class with class_exists() and is_subclass_of($class, Model::class) before querying — never pass a guessed string straight into app() or new.

Testing. Add one test that iterates your app/Models directory and asserts the guesser round-trips each model back to its table and expected route key. This catches the moment a convention drifts and turns a silent runtime failure into a failing test.

it('guesses correctly for every model', function () {
    foreach (File::files(app_path('Models')) as $file) {
        $class = 'App\\Models\\' . $file->getFilenameWithoutExtension();
        expect(guess_table($class))->toBe((new $class)->getTable());
    }
});

Integration tips. Call guessers at the edge (request/command entry points), not deep in domain code — guessed values are inherently unreliable and should be resolved once, validated, then passed as concrete values. If you use the package inside a loop over many resources, memoise results in a static array or a small cache; reflection-based guessing is not free.

Gotchas and Tips

• 1.0.0 is a first release with an empty changelog. Pin the exact version in composer.json and diff src/ before any upgrade. Expect breaking changes in helper names or return types in the 1.x line until the API stabilises.
• Guessing is heuristic, not authoritative. Models with a custom $table, a non-standard namespace, a $primaryKey override, or a morph map will defeat naive conventions. Anything polymorphic should bypass the guesser entirely and use explicit config.
• Watch pluralisation edge cases. Irregular plurals and compound names (Person, Category, BlogPost → blog_posts) are where guessers most often diverge from your schema. Cover these in the round-trip test above.
• Global helper collisions. Helper-function packages can clash if another package defines the same function name. If you see Cannot redeclare after install, run composer dump-autoload -o and check for duplicates before filing a bug.
• Prefer the namespaced API if one exists. If the package exposes both global helpers and a class/facade, use the class form in application code — it is easier to mock and less likely to collide.
• Debugging a wrong guess. In tinker, call the guesser directly against the string and the class to see which direction is failing, then inspect the model's getTable(), getForeignKey(), and namespace. Nine times out of ten the input format (kebab-case vs snake_case vs StudlyCase) is the culprit, not the package.
• Extension points to look for. A publishable config with a class-prefix or namespace map is the cleanest way to adapt the guesser to a non-default App\Domain\... layout; otherwise subclass or wrap the helpers behind your own resolver as shown above. Avoid editing vendor files — 1.0.0 has no BC guarantees to protect you.