yakeing/str_increment
yakeing/str_increment provides a simple str_increment() helper for Laravel and PHP apps, letting you increment strings such as a to b, z to aa, or 9 to 10. Useful for generating sequential codes, invoice numbers, and other alphanumeric identifiers.
This is a single-purpose utility: it takes a string and returns the "next" one in a sequence (a → b, Z → AA, 0f → 10). Treat it as a 10-minute read, not a framework.
Install and pin. The repo is archived and the last release is from 2019-08-06, so do not use a floating constraint:
composer require yakeing/str_increment:^1.0 # confirm the exact tag with `composer show -a yakeing/str_increment`
If Packagist resolution fails or you need the source of truth, add the VCS repo explicitly and pin to a commit hash. Commit composer.lock and vendor the lockfile in CI — nothing here will ever be patched upstream.
Look here first. Open the repository's src/ directory. There is effectively one class; read it end to end before writing any code. Confirm three things, because the README is thin:
Write a five-line smoke test that pins those answers:
use Yakeing\StrIncrement\StrIncrement; // verify against src/
$inc = new StrIncrement();
var_dump($inc->increment('a')); // 'b'
var_dump($inc->increment('Z')); // carry behaviour — record what you actually get
var_dump($inc->increment('ff')); // hex behaviour
First real use case. Sequential human-readable suffixes for generated identifiers: invoice numbers (INV-2024-AAB), coupon batches, SKU variants, or spreadsheet-style column labels (A…Z, AA…AZ) for CSV exports. Anything where you need "the next code" without a database sequence.
Before you build on it, consider not using it. For most teams the correct move is to copy the class into app/Support/ (keeping the MPL-2.0 header) and delete the dependency. It's ~100 lines of pure string manipulation with no transitive dependencies, and an archived package is a supply-chain liability you can eliminate for free. Use Composer only if you genuinely want the version boundary.
Batch generation. The dominant pattern is a loop, not a one-shot call. Generate a run of codes from a seed and hand the last one back to the caller as the new high-water mark:
function nextCodes(string $seed, int $count): array
{
$inc = new StrIncrement();
$out = [];
$cur = $seed;
for ($i = 0; $i < $count; $i++) {
$cur = $inc->increment($cur);
$out[] = $cur;
}
return $out; // caller persists end($out) as the next seed
}
Fixed-width codes. If your identifiers must be uniform length (very common for SKUs and sortable keys), the increment result will change length at carry boundaries. Wrap the increment and re-pad to width on every call, and treat "overflow past max width" as an explicit error rather than silently emitting a longer string:
$next = str_pad($inc->increment($cur), $width, '0', STR_PAD_LEFT);
if (strlen($next) > $width) {
throw new RangeException('Identifier space exhausted');
}
Column-label export. For A…Z, AA…AZ style headers, drive it from the uppercase alphabet mode and cache nothing — the call is trivially cheap, so just increment in the export loop.
Persistence pattern. Never generate the next code inside a request without a uniqueness guard. The class is stateless, so two concurrent workers seeded identically will produce the same value. Use a UNIQUE index on the code column and retry on duplicate-key, or generate under a row lock on the counter row. Do not use SELECT MAX(code) plus this class — that's a race.
Wrapping it. Put a thin adapter in your own codebase (App\Support\SequenceGenerator) so the rest of your app never references the vendor namespace. That gives you a single swap point if you replace the package with an in-house implementation, and one place to normalise the API if you later discover the method signature differs from what you assumed.
Seed from data, not from constants. Persist the last-used seed in a settings table or a dedicated sequence column, then rebuild state by loading the seed. Because the class holds no internal state, this is a pure function of the seed — easy to test, easy to replay.
Archived means frozen. No PHP 8.x compatibility fixes, no security patches, no response to issues. Test on your target PHP version specifically for deprecation notices — a 2019-era class may rely on loose comparisons, strlen/ctype_* on non-strings, or dynamic properties that warn under 8.2. If deprecations appear, patch by copying the file rather than forking the dependency.
License is MPL-2.0, and that's file-level copyleft. Using it as a Composer dependency is fine. Copying the file into your app is also fine, but if you modify that file you must make the modified source available under MPL. Keep the header comment intact; if you patch around PHP 8 warnings, put your changes in your own wrapper or in a separate file so you don't turn a trivial dependency into a compliance question.
Carry behaviour is the thing to test. The only genuinely interesting semantics here are what happens at the end of an alphabet — whether z wraps to a, becomes aa, or returns false/empty. This differs between implementations and the README likely doesn't say. Pin it with a data-provider test on day one, including the empty string, a single character, and a string of maximum width.
Case and character-set selection is not self-evident. Whether the class infers the alphabet from the input or requires an explicit mode argument is the most common source of "it did something weird" bugs. Mixed-case inputs (aZ) may take a branch you didn't expect. Validate the seed against the alphabet you intend before incrementing — reject anything containing characters outside your allowed set rather than relying on the class to complain.
Numeric-looking strings. "9" incrementing to "10" is fine until you sort lexicographically and get "10" < "9". If codes are used as sortable keys, either fix the width or store a separate integer ordinal column. Never rely on string sort for ordering generated codes.
No Unicode/multibyte support. This is byte-and-ASCII oriented. Don't feed it emoji, accented characters, or anything outside the Latin alphabet the class advertises.
Not a token generator. Output is fully predictable given a seed. Use random_bytes for anything with a security or unguessability requirement; use this only for human-facing, non-secret sequences.
Debugging. There is no logging hook and no extension point — no interface to implement, no events. Debug by diffing input against output on the smallest failing case (increment('z')) rather than tracing through the class. If you need configurability (custom alphabets, wrap-vs-throw), subclass or, better, write your own 40-line implementation; the package's design deliberately doesn't offer extension points.
CI hygiene. Run a composer outdated report on a schedule so the archived status stays visible in review, and add a note to your dependency policy that this package is exempt from the usual "upgrade within N days" rule because there will never be an upgrade.
How can I help you explore Laravel packages today?