Sequence Bundle Laravel Package

Technical Evaluation

Verdict up front: this is a Symfony bundle, not a Laravel package. The repository name (sequence-bundle), the description, and the bundle-style architecture mean it targets Symfony's kernel/DI/config-compiler stack. For a Laravel codebase, this is not an integration — it is a rewrite with the source as reference material. Combined with a composite score of 0.375, 5 stars, 0 dependents, and a last release of 2020-03-07, the correct TPM framing is "evaluate as a design reference, do not adopt as a dependency."

Architecture fit

• Framework mismatch is the headline risk. Symfony bundles register services through DependencyInjection/Extension, Configuration trees, and a *Bundle class loaded via bundles.php. Laravel has no loader for this. There is no ServiceProvider, no config/*.php publish tag, no migration stub in Laravel's format — so nothing in the package is directly consumable.
• What is transferable is the domain model: a named sequence with a stored current value, an increment, format/padding rules (prefix, suffix, date tokens), and a reset policy (none / daily / monthly / yearly). That model is the actual IP, and it is small — on the order of a few hundred lines to reimplement idiomatically.
• Persistence almost certainly runs through Doctrine ORM/DBAL. Laravel uses Eloquent plus the DB facade, so even the concurrency primitives differ in call shape (Doctrine LockMode::PESSIMISTIC_WRITE vs. Laravel lockForUpdate()), though both map to SELECT ... FOR UPDATE.

Integration feasibility

• Low-to-none as a drop-in. Getting this to run under Laravel would mean pulling in Symfony's DI container and likely Doctrine alongside Eloquent — two ORMs, two connection pools, two migration systems, one of which is unmaintained. That is a disproportionate blast radius for a number-generation utility.
• High as a reference. A Laravel-native implementation is a one-day spike: a sequences table (name unique, current_value, increment, reset_policy, last_reset_at), a Sequence model, a SequenceService, and a lockForUpdate() inside a transaction.
• Zero dependents is a strong negative signal here. There is no evidence of production use at scale, no downstream issue reports to mine for edge cases, and no community pressure to keep it alive.

Technical risk

• Abandonment. Last release March 2020 puts it in the Symfony 4.4/5.x era. It will not support Symfony 6/7 without maintenance, and the PHP code inside is likely pre-8.0 style — missing return types, no constructor promotion, possibly deprecated patterns. Porting means porting legacy idioms, not borrowing good ones.
• Bus factor of one. A single maintainer, no commits in ~5 years, no security response path. Even the MIT license (which is fine and permissive) doesn't help you get a CVE patched.
• Concurrency semantics are the real correctness surface, and they are exactly what you cannot verify from the outside. A naive sequence implementation reads-then-writes and produces duplicates under load.
• Format/reset edge cases — timezone of the daily reset boundary, behavior on rollback, overflow past the padding width — are where numbering systems actually break in production, and there's no test coverage signal to lean on.

Key questions to resolve before any decision

1. Do we actually need this package, or are we standardizing on a sequence capability we should own? (Owning ~300 lines of heavily-tested numbering logic is usually cheaper than owning a framework port.)
2. What are the real requirements: gap-free, or merely unique-and-monotonic? Gap-free is dramatically more expensive (requires serialized access or a compensating design) and is often a mistaken requirement.
3. Which sequences, at what volume? Invoice numbers at 10k/day are a different design problem than a 3-per-second hot counter.
4. Is the format spec (prefix/date tokens/padding) business-critical and already documented elsewhere, or is the package's config schema the only spec we have?
5. Multi-tenant? If sequences must be scoped per tenant, that changes the uniqueness key and the lock granularity.
6. Does the DB layer support SELECT ... FOR UPDATE in our target engine (MySQL InnoDB, Postgres yes; some managed/serverless options no)?

Integration Approach

Stack fit

• Assume a standard Laravel stack: PHP 8.1+, Eloquent or Query Builder, MySQL/Postgres, PHPUnit/Pest, Composer. The bundle's Doctrine + Symfony DI assumptions do not fit, and forcing them in creates a second framework inside the first.
• Recommended path: build, don't port. Create an internal acme/sequence package with a SequenceServiceProvider, a publishable migration, a config file mirroring the bundle's intent (sequence definitions, format tokens, reset policy), and a thin facade. This keeps the dependency graph clean and gives us full control of the concurrency contract.

Migration path

• Since Dependents: 0 and there is no existing Laravel installation, there is no data migration in the classic sense. The migration is conceptual: transcribe the bundle's sequence definition schema into a Laravel migration, and seed current_value from whatever the current ad-hoc numbering source is (often MAX(id)+1, which is itself a latent duplicate bug worth fixing during this work).
• One-time backfill: derive the starting value per sequence from existing records, then lock the sequence table and reconcile before cutover. Do this in a maintenance window or behind a feature flag.

Compatibility

• PHP 8.1/8.2/8.3 and Laravel 10/11 are the target matrix; write the replacement against them from day one with strict types and return types.
• DB portability: keep the locking strategy explicit per driver. lockForUpdate() is correct on MySQL/Postgres; document that SQLite (used in CI) silently ignores it, so concurrency tests must run against the real engine, not SQLite.
• If some future need requires consuming the Symfony bundle directly, isolate it behind an adapter interface rather than letting it leak into domain code.

Sequencing

1. Spike (1–2 days): read the bundle source, extract the format/reset semantics, decide gap-free vs. unique-only.
2. Design review: agree the sequence table schema, lock strategy, and reset timezone with the team; confirm the API surface (next($name), current($name), reset($name)).
3. Implement + test: unit tests for formatting, integration tests for concurrency (parallel processes contending on one sequence), and a rollback test proving behavior on transaction abort.
4. Backfill + cutover behind a flag, with a reconciliation check.
5. Only then consider whether any residual need justifies keeping the upstream repo as a reference fork — it likely won't.

Operational Impact

Maintenance

• Adopting the bundle transfers a dead dependency into our tree: no upstream fixes, no PHP 8+ modernization, no security triage. Every future PHP or framework upgrade becomes our problem, and we would be maintaining a Symfony-shaped artifact inside a Laravel app.
• Owning a ~300-line internal package costs a fraction of that: one small surface, our own test suite, our own upgrade cadence. The bundle's main value is as a specification of behavior, not as code we run.
• Housekeeping: vendor the MIT-licensed source as a read-only reference if we transcribe logic, with attribution, to keep the license story clean.

Support

• No support channel, no issue triage, no release cadence. Internal on-call would own any failure with zero upstream escalation path. For a component that produces invoice or order numbers, that is an uncomfortable place to be — numbering failures are customer-visible and often legally meaningful.
• The replacement should have a named owner on the platform team and a runbook covering "sequence exhausted," "duplicate detected," and "manual reset."

Scaling

• The likely bottleneck is row-level lock contention on a hot sequence row: every allocation serializes on one SELECT ... FOR UPDATE. At moderate volume (hundreds/sec) this is fine; at high volume it becomes the write hotspot.
• Mitigations to design in from the start: allocate in blocks (reserve N values per request, cache the remainder), separate connection/transaction for the sequence read to shorten the critical section, and consider per-tenant or per-range sharding if contention appears.
• Reset policies add a burst pattern — a month-end or midnight rollover concentrates allocations. Test that boundary explicitly.

Failure modes

• Duplicate numbers under concurrency — the classic read-then-write bug. Highest severity; directly observable by customers.
• Gaps from rolled-back transactions — an allocated value is consumed inside a transaction that aborts. Usually acceptable; must be explicitly accepted by the business, because "gap-free" is a much more expensive promise.
• Reset boundary ambiguity — a daily reset evaluated in UTC while the business operates in local time produces either a day of duplicates or a day of gaps.
• Overflow — exceeding the padding width (e.g., 6 digits) flips formatting behavior; decide now whether to widen, error, or wrap.
• Lock wait timeout / deadlock — a long-running transaction holding the sequence row stalls all allocation. Keep the sequence allocation in its own short transaction.
• Orphaned sequences — sequences defined in config but never seeded (or vice versa) fail at the worst moment; validate on deploy.

Ramp-up

• Low for the replacement: any mid-level Laravel engineer can own it after reading the code and the tests. The domain complexity is in the policies (gap tolerance, reset semantics, format spec), not the implementation.
• Higher for the bundle: someone must learn Symfony bundle wiring and Doctrine locking just to evaluate it, and that knowledge is throwaway.
• Ramp-up artifact to produce: a one-page decision record capturing gap-free vs. unique-only, reset timezone, format tokens, and the overflow policy — this is the durable output of the evaluation, regardless of whether any code is reused.

Bottom line for the portfolio: treat indragunawan/sequence-bundle as an architectural reference, not a dependency. The 0.375 score, 5 stars, zero dependents, and a 2020 last release all point the same way, and the Laravel/Symfony mismatch settles it. Fund a short internal build instead, and recycle the bundle's behavior spec into our own tests.