Code Generator Bundle Laravel Package

Product Decisions This Supports

• Feature scoping for every code-issuance surface. Promo codes, referral codes, invite/access codes, voucher and PIN batches, order references, license keys, short-link slugs. Reading this bundle surfaces the product-visible parameters you'll have to decide anyway: alphabet (drop 0/O, 1/I/L so support can read codes over the phone), length vs. batch size, case sensitivity, prefix/format conventions, checksum digits, and retry-on-collision behavior.
• Build vs. buy vs. borrow. The honest framing is "borrow the logic, own the code." The reusable asset is roughly a day's worth of generation logic plus a uniqueness pattern — not a maintained library. The real options are (a) implement in-house against a database unique constraint, (b) adopt a maintained library for the narrow piece you need (ramsey/uuid, hidehalo/nanoid-php, Laravel's Str::random with a custom alphabet), or (c) pay a voucher/promotions platform if you also need redemption, expiry, batch tracking, and reporting. This package informs (a) and (b); it does not justify (c) on its own.
• Uniqueness and abuse policy as a product decision. Code entropy determines whether you need rate limiting, enumeration protection, and single-use enforcement at redemption. That's a fraud-prevention roadmap item, not just an engineering detail.
• Roadmap sequencing. Whether code issuance is a v1 must-have or a later optimization — and whether current volume is low enough that an ops-generated batch is acceptable for the first release.
• A negative decision, made cheaply. Spending thirty minutes reading this instead of a sprint integrating it is itself the value. It lets you say "we evaluated it, here's why we built our own" with evidence.

When to Consider This Package

• Only as reference reading. Adopt it as a design prompt and a checklist of generation-policy tradeoffs. Do not add it as a dependency.
• Framework mismatch is a hard blocker for Laravel. This is a Symfony2 bundle — a Bundle class, a DependencyInjection extension, Doctrine mappings, XML service definitions. No service provider, no facade, no publishable config, no Laravel integration of any kind. Bundles are Symfony's packaging unit; Laravel has no equivalent loading path.
• Installation is effectively impossible, not merely inadvisable. composer require will fight Laravel's Symfony 6/7 components on version constraints. Co-installation means unsatisfiable graphs or downgrading the host framework.
• Maintenance signal is negative on every axis. Zero stars, zero dependents, no visible CI, no CVE feed, no upstream. Symfony2 has been EOL since 2018; the PHP floor is likely 5.3–5.6, which will fatal on PHP 8.
• Two claims need verification before any partial reuse: is uniqueness enforced by a database unique index with bounded retry (safe) or an in-memory "already used" check (races under concurrency, produces duplicates in production)? And is the RNG random_int/a CSPRNG, or mt_rand/uniqid (a direct enumeration vector for vouchers and invite tokens)?
• Look elsewhere or build in-house when: you're on PHP 8+ or Laravel (i.e., almost certainly), you need true atomic uniqueness, you need redemption/expiry/batch/reporting, or your volume makes collision probability material.

How to Pitch It (Stakeholders)

To executives: This is not a package we should adopt. It's a short read of a code-generation class, not a maintained dependency — zero stars, zero dependents, built for a Symfony 2.x era that's been out of support since 2018. Taking it on adds an unmaintained, unpatched component to our supply chain in exchange for logic we can own outright in about a day. Adoption risk is permanent ownership of a dead code path; the upside is a head start measured in hours. Recommendation: fund a small in-house implementation backed by a database uniqueness constraint, and use this repository strictly as documentation.

To engineering: There is no Laravel glue — "adopting" it means copying the algorithm and rewriting every integration artifact (service registration, config, persistence). Use it as a design prompt: it enumerates the alphabet, length, entropy, and collision-handling tradeoffs. The implementation should be ours — a single CodeGenerator service with configurable alphabet and length, random_int-based selection, persistence via Eloquent with a unique index on the code column, and a bounded retry loop on duplicate-key exceptions. Concurrency-test it before shipping.

The ask: Approve a small in-house build (or a maintained library for the narrow piece we need), and treat this repository as reference material rather than a dependency.