Auth For Laravel Laravel Package

Getting Started

This package provides a configurable authentication layer for Laravel: a published users-table migration, an authentication:guard artisan command that generates guard-specific migrations, and model factories that respect a swapped-in host model. Start by requiring it and publishing what you need:

composer require roundly-consulting/auth-for-laravel
php artisan vendor:publish --tag=auth-for-laravel-config
php artisan vendor:publish --tag=auth-for-laravel-migrations
php artisan migrate

Look at the package config file first — it is where the model class, table name, and guard definitions live. Everything else (factories, migrations, the schema macro) derives from those values.

Your first real use case is almost certainly "add a second guard." Run php artisan authentication:guard <name>, review the generated migration, and migrate. That command is the intended extension point; the published users migration and the generated guard migrations both call $table->authenticationColumns(), so you should not hand-roll the column definitions.

If you use static analysis, confirm phpstan/extension-installer is in your dependency tree. If it is, you get the shipped PHPStan extension for free. If not, add vendor/roundly-consulting/auth-for-laravel/extension.neon to your phpstan.neon includes — see Gotchas.

Implementation Patterns

Swap the model, keep the package. The supported customization is to point the package config at your own User (or equivalent) class rather than editing vendor-published migrations. As of 1.2.2 the shipped factories correctly build whatever model is configured, so a swapped host model is a first-class path rather than a workaround. Define the model override once in config, then use the package factories in tests exactly as you would the defaults.

One migration per guard. Treat authentication:guard <name> as a scaffolding command, not a one-shot. Generate the migration, read it, and commit it — the generated file is the record of what your guard needs. Avoid editing the published base users migration to add guard-specific columns; that conflates the shared schema with per-guard schema and makes later package upgrades noisier.

Factories in feature tests. With the model swap fix, a pattern like $this->configureModel(Admin::class) in a test's setUp followed by Admin::factory()->create() behaves as expected. If you were previously overriding factories or building models by hand to dodge the old behaviour, remove those shims — they now mask real regressions.

Static analysis in CI. Add PHPStan/Larastan as a normal CI step. With the extension installed, a migration that calls $table->authenticationColumns() analyses cleanly instead of erroring with "Call to an undefined method." This matters most in exactly the setups people run in CI: Testbench-based package development and apps using dont-discover.

Compose with Laravel's own auth config. Keep guard and provider definitions in config/auth.php aligned with whatever the package config declares. The package supplies schema and model plumbing; it does not replace Laravel's guard resolution, so mismatches between the two files are your problem, not the package's.

Gotchas and Tips

The schema macro only exists after its provider boots. authenticationColumns() is a runtime macro, not a static declaration. Anything that parses a migration without booting the provider — static analysis, some tooling, a bare Testbench harness — will see it as an undefined method. The 1.2.2 PHPStan extension is the fix for the analysis case; it does not make the macro available at runtime in a misconfigured app. If you hit "Call to an undefined method" at runtime, check that the provider is actually registered and not excluded.

The PHPStan extension is opt-in in disguise. It is wired via extra.phpstan.includes, which is only honoured by phpstan/extension-installer. Without that package installed, the extension silently does nothing and you get the original error back. Explicitly include vendor/roundly-consulting/auth-for-laravel/extension.neon in phpstan.neon if you are unsure — a redundant include is cheaper than a confusing failure.

Package development under Testbench is the sharp edge. The release notes call this out specifically: this is the environment where auto-discovery does not do what you expect. If you are developing a package that depends on this one, or testing this one, expect to configure the provider and the PHPStan include by hand.

dont-discover and manual providers. If you list providers explicitly, remember this one. A missing provider produces a runtime macro error that looks like a package bug and is actually configuration.

Config caching. Swap the model in config, then clear cached config (php artisan config:clear) before concluding the swap did not take. Model-swap symptoms under a stale cache look identical to the pre-1.2.2 factory bug.

Upgrade note. 1.2.2 is a patch release with no breaking changes, no deprecations, and no new configuration surface — it is safe to take on any 1.2.x install. If you had worked around either the factory/model-swap behaviour or the PHPStan error, remove those workarounds at the same time so you notice if either regresses.