Product Decisions This Supports
- Build vs. buy for sequence generation (invoice numbers, order IDs, SKUs, ticket numbers). This package is a reference implementation of the "don't hand-roll your numbering" decision. It gives you a working mental model of configurable, named sequences with per-sequence strategies and storage backends, which is exactly the kind of thing that looks trivial at kickoff and becomes a reconciliation nightmare in month nine.
- Feature scoping for the "document numbering" epic. Use it to size the work: named sequences, prefix/suffix formatting, starting values, increment steps, and persistence. If your roadmap includes finance, e-commerce, or any regulatory-facing document flow, this defines the minimum viable surface area of that feature.
- Roadmap signal — flagging a cross-cutting dependency early. Numbering is usually specced late and touches orders, invoices, credit notes, and exports simultaneously. Recognizing the shared primitive now prevents four teams from each shipping their own counter.
- Architecture direction for multi-tenant and multi-entity numbering. Per-tenant, per-year, per-branch sequences (e.g.,
INV-2025-0001 vs. INV-2025-0002) is a configuration problem, not a code problem. This package's shape — named sequences with strategy objects — is the argument for keeping numbering in configuration.
- Vendor/stack fit as a gate on the build-vs-buy call. The strongest decision it supports is the negative one: this is a Symfony bundle, not a Laravel/PHP-framework-agnostic library, and the brief's framing as a "Laravel/PHP package" is a mismatch. That directly answers "can we adopt this as-is?" with no.
When to Consider This Package
Adopt (or, more realistically, study and port) when:
- Your stack is Symfony with Doctrine, and you need monotonic, configurable sequence generation without writing it yourself.
- You want named sequences with pluggable strategies rather than a
SELECT MAX(id) + 1 pattern scattered across services.
- Your numbering rules are configuration-shaped (prefixes, reset cadence, step size) and you want them outside business logic.
- You are comfortable owning a dependency with 5 stars, zero dependents, and no release since March 2020 — i.e., you are prepared to fork it and treat it as internal code.
Look elsewhere — or build it — when:
- You are on Laravel. This is the dominant caveat. A Symfony bundle will not drop into a Laravel app; there is no service container bridge, no Doctrine-by-default assumption that survives, and you would be rewriting the wiring anyway. At that point you are buying a design, not a package.
- You need active maintenance or a security posture. No releases in ~5 years and no dependents means no downstream pressure to fix anything. Sequence generation sits on the critical path of every order and invoice — a stale dependency there is an availability risk, not a style preference.
- You need gap-less sequences under concurrency. Numbering correctness under parallel writers (row locking, atomic increments, retry semantics) is the entire difficulty of the problem. Verify this implementation's guarantees against your actual isolation level before you rely on it; a low-activity repo rarely has battle-tested concurrency handling.
- Your requirements are simple enough to be a database sequence or a
unique constraint plus formatting. Buying a bundle to do nextval() is over-engineering.
- You need distributed or offline-friendly ID generation. If you're sharding or generating documents at the edge, monotonic centralized sequences are the wrong primitive and this package is the wrong shape.
How to Pitch It (Stakeholders)
To executives: This package is a small, MIT-licensed reference for generating sequential document numbers — invoices, orders, tickets — with configurable formats and starting points. We are not recommending adoption. It is a Symfony component with five GitHub stars, no downstream dependents, and no release in five years, and our stack is Laravel. The value is as a design reference for a feature we will build ourselves: it shows the shape of the problem and gives us a head start on scoping, at zero cost and zero ongoing dependency risk. The business decision is to treat numbering as a first-class, centrally-owned capability before three teams invent three different invoice counters.
To engineering: Numbering is a shared primitive, not a per-service detail. This bundle models it well — named sequences, strategy objects, configuration-driven formats — and that decomposition is worth copying. It is not worth depending on: Symfony-only, unmaintained since 2020, no dependents, and concurrency behavior unverified. Recommendation: port the pattern, not the package. Budget a small internal library or a Laravel-native equivalent with an explicit contract covering sequence naming, format templating, reset cadence, and — critically — atomicity and gap semantics under concurrent writes. Write the concurrency tests first; that is where this class of feature fails, and it is where a five-year-old package gives us no assurance.