Strength Meter Laravel Package

Getting Started

This release is a good entry point for anyone wiring a password-strength UI into Laravel auth flows: the additions are mostly polish (translations, Bootstrap 4, configurable minimum length) wrapped around a breaking change to plugin initialization and events from enh #21.

Minimal steps:

1. composer require the package (or pull the updated tag if you already have it), then publish its config and JS/public assets:

   php artisan vendor:publish --provider="...\ServiceProvider" --tag=config
   php artisan vendor:publish --provider="...\ServiceProvider" --tag=assets
   

2. Look first at the published config file for the rules block — v1.1.4 adds rules.minLength (defaults to 2), and enh #13 changed how defaults are merged, so review the full merged array rather than just overriding one key.
3. Look second at the README's JS init snippet, since the initialization API changed. Anything copy-pasted from a pre-1.1.4 tutorial will break.
4. First real use case: drop the meter into the registration and password-reset Blade views, bind it to the password input, and mirror rules.minLength in your RegisterRequest / PasswordController validation so client and server agree.

If you only need server-side enforcement, you can ignore the JS entirely and use the rule/config layer — but the value of the package is really the UI feedback, so plan on both.

Implementation Patterns

Blade integration. Publish a small partial (resources/views/vendor/.../password-field.blade.php or your own) that renders the input plus the wrapper element the plugin expects, and @include it in both register and reset forms. Keep the markup in one place — the Bootstrap 4 support in enh #20 means the wrapper/DOM shape differs from Bootstrap 3, and you do not want that decision scattered across views.

Mirror the rules, don't duplicate them. Treat rules.* as the single source of truth for UX, and your FormRequest as the source of truth for security. A common pattern:

// config/password-strength.php -> rules.minLength
// app/Http/Requests/RegisterRequest.php
'password' => ['required', 'confirmed', Rule::min(config('password-strength.rules.minLength', 8))],

Pass the config into the view so the JS and PHP read the same number:

return view('auth.register', [
    'passwordRules' => config('password-strength.rules'),
]);

Event handling after the BC break. Enh #21 reworked plugin initialization and events. Register behaviour via the new event API rather than the old callbacks. Typical workflows:

• On strength-change: toggle the submit button's disabled state (do this in JS only as a convenience — never as the sole guard).
• On validation-fail: surface a message near the field rather than a global alert.
• On init-complete: attach your own listeners, so you don't race the plugin's setup.

Bootstrap 4 vs 3. Enh #20 adds Bootstrap 4 support, but you almost certainly have to select it (config flag, template option, or a v4-specific init call). Pick one framework per app — don't try to support both simultaneously in the same layout.

Translations. v1.1.4 adds Serbian, Spanish, Hungarian, and Polish. Publish the language files, set the locale per-request (App::setLocale() or the ?lang middleware), and verify fallback behaviour. If your app already ships its own i18n strings for the field labels, use the package translations for the strength meter text and keep your labels separate.

Extending defaults. Enh #13 ("better extending of default options") means you can now supply a partial options array without clobbering siblings. Pattern: publish config, override only the keys you care about, and let merge logic handle the rest. If you previously re-declared the entire options array to work around merge issues, remove that duplication — it will silently drift from upstream defaults.

Testing. In feature tests, assert your FormRequest rules independently of the JS package. For the UI, a Dusk/Playwright smoke test that types a short password and asserts the strength element updates will catch init regressions (the most likely breakage from #21).

Gotchas and Tips

• The BC break is the headline. Enhancements to "plugin initialization & events" in #21 means existing JS call sites may throw or silently no-op. Grep your codebase for the old init function name and old event/callback names. If in doubt, re-copy the init block from the updated README.
• rules.minLength defaults to 2. That is a UX default, not a security policy. Almost everyone should raise it to at least 8 (or whatever your server-side rule enforces). Leaving it at 2 produces a meter that says "strong" for passwords your backend will reject — the worst of both worlds.
• Mismatch between client and server rules is the most common bug in this class of package. If the meter is green but the request fails validation, users will report it as a broken form. Always derive both from one config value.
• Bootstrap 4 markup produces different classes and wrapper elements; if you upgrade Bootstrap without also enabling v4 support in the plugin, the meter will render unstyled or position oddly. Check both at once.
• Assets and cache busting. After upgrading, run php artisan vendor:publish --force for assets and clear view/config caches (php artisan optimize:clear). Stale published JS from a previous version is a very common "the BC break still happens" false alarm.
• Translations silently fall back. If a locale file wasn't published or the locale code doesn't match (sr vs sr_Latn, es vs es_MX), the plugin falls back to English with no error. Verify the string actually changes when you switch locale.
• Debugging tips. Watch the browser console for init errors (the #21 breakage surfaces here), inspect the wrapper element to confirm the meter DOM is being created, and log the resolved options object right after init — with the new merge behaviour, seeing the final merged config is far faster than reading the source.
• Extension points. Prefer the config merge (enh #13) and the new event hooks over monkey-patching the plugin's JS. If you need custom scoring, look for a rules/callback extension rather than editing vendored assets, so the next update doesn't wipe your changes.
• Upgrade checklist for this version: (1) re-publish assets/config, (2) update init + event listeners for #21, (3) set Bootstrap version explicitly for #20, (4) raise minLength from the 2 default, (5) publish new language files if you use non-English locales, (6) remove any full-options overrides you added to work around the old merge behaviour.