- Can I install lightmaker/complexify-bundle in a Laravel application?
- No. lightmaker/complexify-bundle is a Symfony2 bundle, and Laravel has no mechanism to load Symfony bundles; its DI extension, Configuration tree, and YAML service definitions cannot be read by the Laravel container. The only genuinely reusable asset is the standalone PHP scoring class, which you would vendor or fork rather than require as a package. For Laravel, use a maintained library such as bjeavons/zxcvbn-php or write the check in-house.
- What does the Complexify bundle actually do?
- It integrates the Complexify strength meter into Symfony forms through a form type and a validator, so users get live feedback while a server-side rule enforces the same threshold. Complexity thresholds and validation messages are configurable, and the messages are translation-ready. It was designed for registration, password reset, and profile forms.
- Does Complexify bundle work with PHP 8 and modern Laravel versions?
- Almost certainly not without changes. The last release was 2016-04-29, Symfony2 reached end of life in January 2017, and the code assumes PHP 5.6/7.0-era semantics. Dynamic properties, each(), curly-brace string offsets, and implicit nullable parameters are all likely to surface on PHP 8.x, so runtime compatibility must be proven with a test matrix rather than assumed.
- What is a good Laravel alternative to Complexify for password strength checking?
- bjeavons/zxcvbn-php is the usual choice: it is actively maintained, uses a real dictionary and matcher model, and is the de facto standard for PHP password strength estimation. Bind it behind a first-party PasswordStrength contract and expose it through a thin Laravel service provider so the implementation stays swappable. That gives you maintained scoring with a Laravel-native API.
- Is lightmaker/complexify-bundle still maintained?
- No. There has been no release since April 2016, the repository has effectively zero stars, forks, and dependents, and there is no maintainer, issue triage, or security advisory channel. Adopting it means taking full ownership of unmaintained, security-adjacent code. For production work, treat it as abandoned.
- Should password strength be checked client-side or server-side?
- Pick one authoritative side and stick to it. Complexify is fundamentally a client-side heuristic for keystroke feedback, with a PHP port bolted on, so running both gives you two scoring models that can disagree, for example the UI shows strong while the server logs weak. If you only need UX feedback, most of this package's value disappears and enforcement should live server-side with a different library.
- How do I configure complexity thresholds in the Complexify bundle?
- In Symfony, thresholds live in the bundle's Configuration tree and are injected through the DI extension. Laravel cannot read that configuration, so a port has to move the thresholds into a config file or a dedicated validation rule class. Expect that work to be a rewrite of the wiring, not a copy of the settings.
- Does Complexify align with NIST SP 800-63B password guidance?
- No. The scoring model predates NIST SP 800-63B, which favours length and breached-password blocklists over composition rules, and its common-password dictionary will be years behind current breach corpora. Shipping it risks encoding an outdated password policy into the product. Decide whether you want composition-style scoring at all before adopting it.
- How do I test password strength validation in a Laravel app?
- There are no Laravel test helpers here, and the Symfony form and validator tests do not transfer. If you extract the scoring class, unit-test it against a fixture set of known passwords and assert on score bands rather than exact integers, then test the Laravel validation rule separately. Also cover non-ASCII and long passphrases, since dictionary matchers often degrade there.
- How much work is it to extract Complexify's scoring into Laravel?
- Small but non-trivial. The MIT licence makes extraction clean, so you can vendor mcrumley/php-complexify or fork the scoring class into your own namespace; the payload is roughly a 200-line algorithm, not a framework integration surface. Budget a low single-digit day spike to prove it on PHP 8.x, and accept that you now own unmaintained, security-adjacent code.