Passkeys For Laravel Laravel Package

Technical Evaluation

• Architecture fit: roundly-consulting/passkeys-for-laravel is an idiomatic Laravel package: it registers via service-provider auto-discovery and extends the framework's schema builder with a passkeyUserHandle(): ColumnDefinition macro. That pattern means it augments migrations/persistence rather than replacing the auth guard, so it should slot into an existing Laravel app with low structural friction. The presence of a dedicated schema macro indicates the package owns at least one column convention for the WebAuthn user handle — confirm whether it also manages routes, controllers, and the ceremony (challenge/attestation/assertion) endpoints or expects the host app to wire them.
• Integration feasibility: Low effort. composer require plus auto-discovery covers the default path. The one non-default path is explicitly documented: under dont-discover, manual provider registration, or Testbench-based package development, the provider may not boot during static analysis, so phpstan/extension-installer must be permitted (or vendor/roundly-consulting/passkeys-for-laravel/extension.neon included manually). Both are standard Laravel/PHPStan mechanics.
• Technical risk: Low for 1.1.3. This is a dev-tooling-only patch — no runtime behavior change, no breaking changes, no deprecations. It removes a false positive ("Call to an undefined method") that previously affected CI in specific registration modes. Residual risk is configuration drift, not the package itself: PHPStan extension resolution, Composer plugin allow-listing, and version alignment between the shipped extension.neon and the project's PHPStan major.
• Key questions:
  • Laravel and PHP version support matrix? Supported PHPStan/Larastan versions for extension.neon?
  • Does the package ship the full passkey ceremony (register/authenticate endpoints, challenge storage, replay protection) or only schema + model helpers?
  • What column type does passkeyUserHandle() emit, and is it portable across SQLite/MySQL/PostgreSQL?
  • Multiple credentials per user? Discoverable (resident) credentials? Attestation policy?
  • Storage of credential IDs/public keys — encryption at rest expectations?
  • Is phpstan/extension-installer permitted in our Composer allow-plugins policy, or must we use the manual includes path?

Integration Approach

• Stack fit: Laravel + PHPStan/Larastan on the standard Composer toolchain. If we already run phpstan/extension-installer, the extension loads automatically via extra.phpstan.includes; otherwise we add the extension.neon path to phpstan.neon.
• Migration path: Treat 1.1.3 as a drop-in patch — bump the constraint and composer update. The only corrective work is cleanup: if the "undefined method" error was previously silenced in a baseline, ignoreErrors, or inline @phpstan-ignore, remove those suppressions so the real signal returns and we don't mask future regressions.
• Compatibility: Verify extension.neon parses against our PHPStan major (neon schema changes between majors). Ensure the manual-include path isn't hard-coded in a way that breaks on vendor-path changes; prefer the installer. Check for macro-name collisions if other packages also extend Blueprint.
• Sequencing:
  1. Bump dependency in a branch; confirm composer.lock and allow-plugins entries.
  2. Clear PHPStan result cache and run analysis in CI to confirm the macro is recognized.
  3. Remove obsolete suppressions/baseline entries.
  4. Run the passkey migration against SQLite (CI), MySQL, and PostgreSQL (staging) to validate the emitted column type.
  5. Exercise registration and authentication flows end-to-end before promoting.

Operational Impact

• Maintenance: Small surface. Pin the package version and re-validate extension.neon on each PHPStan major upgrade. Keep phpstan/extension-installer in allow-plugins so the automatic path stays available; document the manual includes fallback for teams using dont-discover.
• Support: Expect fewer "undefined method" tickets from developers running analysis locally or in package-development contexts — a net reduction in noise. New support vector: contributors working under Testbench who must be told the extension exists and how to include it.
• Scaling: No runtime or infrastructure impact; this patch changes nothing in the request path. Static-analysis cost of one extra neon include is negligible.
• Failure modes:
  • Provider not booted during analysis (Testbench, dont-discover, manual registration) → recurring "undefined method" unless the extension is loaded.
  • Composer plugin blocked by allow-plugins policy → extension silently not loaded; CI fails with the original error.
  • PHPStan major mismatch → neon include errors out.
  • Runtime: if the provider is genuinely not registered in production, the migration fails — verify registration in each environment, not just analysis.
  • Database portability: confirm the emitted user-handle column type behaves on every engine we deploy.
• Ramp-up: Developers need baseline WebAuthn/passkey literacy (user handles, credential storage, ceremonies) plus PHPStan configuration familiarity. Budget a short enablement session and a security review of credential persistence before production rollout; the release notes alone do not establish the package's security posture.