Php Passphrase Laravel Package

Product Decisions This Supports

• Build vs. buy for human-friendly secrets. This package eliminates the temptation to hand-roll a wordlist generator for invite codes, temporary passwords read over the phone, support-assisted credentials, or demo/test fixtures. That is a small but real scope item off the roadmap.
• Password/passphrase policy as configuration, not code. num_words, word_separator, capitalize, include_number, bundled wordlists, and an excluded-words list let the PM shape one policy (e.g. "4 words, hyphen-separated, no numbers") and change it via config rather than a sprint.
• Security hardening commitments. v2.2.0 adds a ConfigException with descriptive validation messages, type validation for word lists and excluded words, and PHPStan level 10 analysis. This is the kind of evidence to cite when a security reviewer asks "is config failure loud or silent?"
• Use cases that fit: invite/referral codes, onboarding temp credentials, secrets delivered through low-bandwidth or verbal channels, seeded fixtures for QA.
• Use cases that do not fit: machine-to-machine tokens, API keys, session secrets, or anything needing raw CSPRNG output — those stay with Str::random/random_bytes. Keep the two decisions separate so this package doesn't get over-scoped.
• Supportability signal. Testbench 11 support and the PHPStan bump are maintenance investments; a PM can read them as "the maintainer intends to keep up with the Laravel release train" — relevant if you're standardizing on the newest Laravel major.

When to Consider This Package

Adopt when:

• You are on Laravel (or can tolerate its service-provider wiring) and need memorable, human-transmissible secrets.
• You want a bundled wordlist and Diceware-style generation rather than curating one yourself.
• You are willing to pin an exact version and validate config at boot — v2.2.0 is a beta, and the new ConfigException means previously tolerated (mis)configurations — non-integer num_words, non-string word_separator, non-boolean capitalize / include_number, non-string list entries — will now fail loudly. That's the right behavior, but it is a behavioral change that can surface as a boot-time exception in existing apps.
• Your security posture tolerates a small, single-maintainer dependency for a non-critical-path utility.

Look elsewhere when:

• You need cryptographically strong machine secrets, entropy guarantees you can audit, or FIPS-style compliance — use PHP's CSPRNG directly.
• You need localized or multi-language wordlists, or wordlists you control line-by-line.
• You require a GA (non-beta) dependency with a published support/deprecation policy, or your org gates on maintainer bus-factor.
• You are outside Laravel and want a framework-agnostic generator without the service-provider surface.

How to Pitch It (Stakeholders)

To executives: A small, free dependency that removes bespoke code for the passwords and codes we hand to humans. The new release makes bad configuration fail at startup instead of producing subtly weaker passphrases — a cheap, concrete security win with no product-visible change. Cost is one Composer entry; risk is a low-traffic, single-maintainer package that we should pin.

To engineering: v2.2.0-beta.1 is a hardening release, not a feature release. It introduces ConfigException for config validation (typed checks on num_words, word_separator, capitalize, include_number, word list, and excluded words), raises PHPStan to level 10 with benevolent union checking, adds tests for non-string list elements and invalid config types, improves facade/service-provider docblocks, and adds Testbench 11 support. Practical guidance: audit your config/passphrase.php before upgrading, expect a boot-time throw where config was previously silently coerced, pin the beta tag, and treat the core generator contract as stable while the validation layer settles.