Laravel Nova Profile Laravel Package

Getting Started

This is a 0.0.1 release, so treat the public API as provisional. The package gives you a ready-made authenticated profile page, a User resource for rendering user detail fields, and container-resolved password request / password updater services.

Minimal setup:

1. Require the package with Composer and pin the exact version (0.0.1) until the API stabilises.
2. Publish any package assets/config/views (check the package service provider for publishes() calls) and run migrations if the package ships any.
3. Confirm the profile route is registered — the release notes describe a profile page, so look for a route named something like profile or a configurable URI prefix. Apply your own auth middleware if the package does not.
4. Open the config file first. Route prefix, middleware, guard, and view namespace are the usual knobs.
5. Visit the profile page as an authenticated user. The first use case is simply exposing a self-service profile screen where users can view their account details and change their password.

Where to look first:

• The package service provider: route registration, view namespace, container bindings.
• The published config: route/middleware/guard settings.
• The User resource class: how detail fields are declared and rendered.
• The password request and updater contracts/classes: these are the documented DI extension points.

A realistic first integration is: install, publish config and views, protect the route with your app's auth middleware, then render the page for a logged-in user and submit the password form once to confirm the default updater works end-to-end.

Implementation Patterns

Route and middleware integration. Mount the profile page behind your existing authentication stack. If the package registers its own route, override the middleware in config rather than editing vendor files. If you need a different URL (for example /account/security), use the configurable prefix or re-register the route in your own route file and disable the package route if supported.

Customising the User resource and detail fields. Treat the User resource as the presentation layer for profile data. Extend or replace it to add application-specific fields (display name, avatar, timezone, etc.). Keep field definitions declarative and avoid putting query logic in the resource — resolve any additional data in a controller or view composer and pass it in. If the resource accepts a field list, compose it from config so different apps/environments can toggle fields.

Swapping password services via the container. The release explicitly makes the password request and password updater DI-friendly. The day-to-day pattern is:

• Implement the package's contract (or extend its default class) for your password policy, audit logging, or notification behaviour.
• Bind your implementation in a service provider — typically AppServiceProvider::register() or a dedicated ProfileServiceProvider.
• Resolve through the container; do not instantiate the default updater directly.

This lets you inject your own hasher, password broker, audit logger, or rate limiter without forking the package. A common real-world use is wrapping the updater to dispatch an event or write an audit record after a successful change.

View overrides. Publish the views and override them in your app. Prefer extending the package layout/section rather than copying the entire page, so future package updates are easier to merge. If the package uses Blade components, override the component rather than the page.

Testing. Use actingAs($user) and hit the profile route to assert the page renders expected detail fields. For password changes, bind a fake/spy implementation of the updater contract in the test container and assert it was called with the correct request data. This is the cleanest way to test the DI seam without hitting the real password broker.

Composition with your own profile sections. If the page is extensible, register additional sections (e.g. two-factor authentication, API tokens) alongside the built-in detail fields. Keep each section in its own class/partial and register them from a service provider so the profile page stays declarative.

Gotchas and Tips

• 0.0.1 means no stability promise. Expect class names, config keys, and view names to change. Pin the version and read the source rather than relying on assumed conventions. Do not build deep inheritance on top of package classes yet; prefer the documented DI contracts.
• Verify the DI binding order. If you bind your password request/updater implementation in AppServiceProvider, make sure the package provider is not resolving the service earlier during boot. Bind in register(), not boot(), and avoid resolving the service in a route model binding or middleware that runs before your provider.
• Password updater validation is your responsibility at the edges. The package may handle hashing and persistence, but confirm it validates the current password, applies your password rules, and respects the configured guard. Add a form request or validation layer if the package does not.
• Authorization on detail fields. A profile page is user-scoped; make sure the resource is always resolved for the authenticated user and never for an arbitrary ID from the request. If detail fields include email or other PII, confirm they are only rendered to the owner.
• Route collisions. A generic profile URI can clash with an existing route. Check php artisan route:list after install and adjust the prefix or disable the package route.
• Config caching. After changing package config, run php artisan config:clear (and config:cache in deployment). Published config merged at runtime will not reflect changes while a cached config exists.
• Publishing with --force. Re-publishing views/config will overwrite local customisations. Keep customised views in your app's namespace and publish only once, or track diffs carefully.
• Debugging container resolution. If the wrong password service is used, inspect bindings with app()->getBindings() or resolve the contract in tinker. A missing binding silently falls back to the package default, which can mask configuration mistakes.
• Extension points to watch. The two contracts named in the release notes are the intended extension seams. Confirm their method signatures in the source before implementing; in a 0.0.1 release they may still change between patch versions.