Sequence Bundle Laravel Package

Product Decisions This Supports

• Document numbering policy for commerce and finance — this package’s domain concept maps directly to product decisions around order numbers, invoice numbers, credit-note IDs, shipment references, and return authorizations. The PM-relevant question is not “should we install this?” but “what numbering rules does the business require?”
• Gapless vs. gap-tolerant sequencing — a real product/compliance decision. Invoice numbers in many jurisdictions must be gapless and sequential, while order numbers can usually tolerate gaps. This distinction drives architecture, operational risk, and audit controls.
• Build vs. buy for identifier generation — the honest conclusion is build or use maintained platform primitives. This package is useful as a worked example of the “named sequence + generator + formatted output” abstraction, but not as an adoptable dependency.
• Feature scoping for order/invoice workflows — if the roadmap includes invoice generation, fulfillment documents, or regulated financial records, the numbering approach must be defined before implementation. Sequence bugs are discovered in accounting, not QA.
• Legacy migration risk — if the organization runs a Sylius 1.x / Symfony2-era platform, this identifies a concrete infrastructure component that must be replaced during upgrade. Its archived status makes it a migration risk item.
• Audit and compliance posture — who can reset a sequence, whether numbers can be reissued, how gaps are reconciled, and whether counters are tenant-specific are product/controls questions. They should be documented as policy, independent of this package.
• Vendor and maintenance risk assessment — 4 stars, 0 dependents, archived, read-only. The PM can use this as a clear example of why community validation and maintainer status belong in dependency decisions.

When to Consider This Package

Consider it as a reference, not a dependency, only when:

• You maintain an existing Symfony2 / early Sylius application that already depends on it and need to understand its behavior before replacing it.
• You need a compact reference implementation of named sequences with configurable formats and incrementing counters to inform an in-house design.
• You need to mirror Sylius-compatible order-number semantics for migration, parity testing, or data reconciliation.

Look elsewhere — the default case — when:

• You are building on Laravel or a modern Symfony version. This is a Symfony2-era bundle, archived and unmaintained, with no Laravel service provider, facade, config, or Eloquent integration.
• You need cluster-safe, high-concurrency counters. Prefer native database sequences, Redis INCR, ULIDs, or Snowflake-style IDs depending on whether ordering, gaplessness, or distribution matters.
• You require security patching, PHP-version compatibility guarantees, or vendor support. Archived means no CVE response and no upgrade path.
• You are on Laravel specifically. Use database auto-increment/sequences, Str::ulid() / Str::orderedUuid(), or a small in-house NumberSequence model — a few dozen lines, fully owned.
• You need multi-tenant sequencing, annual resets, prefix/suffix formatting, or audit reconciliation. These are legitimate requirements, but they are better implemented natively than inherited from an abandoned bundle.

How to Pitch It (Stakeholders)

To executives: This is an archived, read-only Symfony2 component for generating sequential document numbers. It has negligible adoption (4 stars, 0 dependents) and no maintenance or security support. Recommendation: do not adopt. It is valuable only as a design reference. The business-relevant issue it surfaces — how we number invoices and orders, and whether those numbers can have gaps — is a compliance and audit decision worth making explicitly, independent of this package.

To engineering: Treat it as documentation, not code. The transferable idea is the sequence abstraction: a named sequence with a format template, a current value, and a generator that increments atomically. Re-implement that in-house in roughly 50–150 lines with the concurrency guarantees the workload needs: row-level locking for gapless invoice numbers, or ULID/Redis for gap-tolerant order IDs. Note that the repository is a read-only split of the Sylius monorepo, so history and issues live upstream; do not fork it as a long-term dependency.

Bottom line: Low effort to replicate, high risk to depend on. Decide the numbering policy as a product and compliance call, then implement it with maintained primitives.