Fuerte Laravel Package

Getting Started

• Install with Composer: composer require collegeman/fuerte. The package advertises zero dependencies, so it won't drag transitive packages into your lockfile.
• In Laravel 5.5+ the service provider should be auto-discovered. On older versions, register Collegeman\Fuerte\FuerteServiceProvider in config/app.php and add the Fuerte facade alias if the README lists one.
• If a config file ships, publish it: php artisan vendor:publish --provider="Collegeman\Fuerte\FuerteServiceProvider". If nothing publishes, there is nothing to configure.
• Look first at the README for the exact method signature, then at src/ — this is a single-purpose generator, so the whole surface area is one class plus a service provider.
• First use case: replace Str::random() / str_random() where you provision accounts, reset passwords, or seed users. The point of Fuerte over Laravel's helper is character-class guarantees (upper/lower/digit/symbol), not raw length.

use Collegeman\Fuerte\Fuerte;

// Confirm the exact method name/options in the README before shipping.
$plain = Fuerte::generate(16);

Implementation Patterns

• Wrap it, don't scatter it. Bind a tiny PasswordGenerator service in the container that delegates to Fuerte. Facade calls are convenient but make it harder to fake in tests and to swap later — and for a package this small, swapping later is realistic.
• Factories and seeders:

  'password' => Hash::make(Fuerte::generate(20)),
  

  Use a fixed length you also validate against, so seeded accounts can't drift from your policy.
• Admin-provisioned accounts: generate, display once in a flash/session, and force a reset on first login. Never email the plaintext.
• Validation parity: add a rule (or a test) that asserts the generator's output passes your own password policy. It's easy for "strong" defaults to exclude a symbol your policy demands.
• Hashing is separate. Fuerte returns a string; pair it with Hash::make() / bcrypt() / argon2. Don't mistake generation for storage.
• Cross-runtime consistency: the package has a JS counterpart. If you offer a "suggest a password" button in the browser, mirror the PHP length/charset settings so client-generated suggestions satisfy the server-side validator.
• WordPress: call the provided helper inside a plugin, guarded with function_exists() so the plugin degrades gracefully if the library isn't loaded.
• Non-password secrets: for API keys, signed-URL secrets, or remember-me tokens, prefer random_bytes() / Str::random(64). Fuerte is tuned for human-transcribable passwords, which is a different optimization target than maximum entropy.

Gotchas and Tips

• Audit the RNG first. The entire value of a password generator is its randomness source. Check whether it uses random_int/random_bytes (PHP) and crypto.getRandomValues (JS). If it falls back to mt_rand/Math.random, do not use it for production credentials, regardless of what the character sets look like.
• Ambiguous-character defaults. Many generators strip 0/O, 1/l/I by default. Great for usability, surprising if your policy or a downstream system expects a specific character mix. Read the defaults.
• Length ≠ strength. 16 chars from a 62-symbol alphabet is ~95 bits; 8 chars is weak no matter how many classes you include. Pick a length deliberately.
• Low-maintenance dependency. 25 stars and a single maintainer means low bus factor. Pin the version ("collegeman/fuerte": "^1.0"), and seriously consider vendoring the generator — it's small enough that copying one file may beat taking the dependency.
• PHP version support. Check require in composer.json; older packages can predate PHP 8 and trip deprecations or type errors under modern runtimes.
• Config caching. If you publish config, remember php artisan config:cache on deploy — stale cached config is the classic "my setting is ignored" bug.
• Don't leak plaintext. Scrub generated passwords from logs, exception handlers, and Telescope. Generated strings look like secrets to log-scrubbers only if you tell them to.
• Testing: assert strlen() and a charset regex, never an exact value. If you need determinism in tests, inject a fake generator rather than reaching for the facade.
• Extension points: if the generator class isn't final, subclass it to add your own alphabet/policy and bind that in the container; otherwise wrap it — which is the safer default either way.