Product Decisions This Supports
- Customer-visible identifier strategy — the real decision behind the package. Whether URLs, API responses, webhooks, exports, and support tooling expose sequential integers or opaque/prefixed identifiers is a product commitment, not a technical detail. It affects URL stability, enumeration/security posture, sortability, pagination strategy, and how support staff debug a customer issue from a single ID. This package is useful primarily as evidence that per-model key formats are cheap to configure — the expensive half (backfilling and dual-writing existing tables) is not solved by it.
- Platform convention vs. per-team improvisation. If two teams are hand-rolling key generation (ULIDs here, UUIDs there, prefixed strings somewhere else), the correct output is a short ADR and a documented default — not a six-star dependency. Cite this package as prior art in that ADR, then standardize on the framework-native path.
- Resolve the category confusion before deciding anything. The name says Eloquent model key; earlier reads treated it as an API credential generator. These are different decisions with different risk profiles. If the need is credentials, the answer is Laravel Sanctum/Passport (issuance, hashing, abilities, expiry, revocation) and this package is irrelevant. If the need is primary keys, the answer is native
HasUuids/HasUlids.
- Build vs. buy vs. framework-native — and the honest verdict is "native." Laravel has shipped ULID/UUID model keys since v9 and token issuance via Sanctum/Passport. The package's defensible role is documented prior art: a ~100-line illustration of the "one place to configure per-model key strategy" pattern you can reimplement first-party behind an internal interface in about a day.
- Schema and API contract lock-in. Key format is effectively irreversible without a migration. ULID vs. UUID vs. prefixed string determines column type, index behavior, sort order, and whether keyset pagination is even possible. Worth deciding once, deliberately, with an owner.
- Explicitly out of scope: token rotation, revocation, scopes/abilities, expiry, rate limiting, audit logging, and idempotency keys. If the roadmap needs any of those, this package is not on the critical path at all.
When to Consider This Package
Consider it as reading material or copy-paste reference, and only when:
- You want a small, MIT-licensed example of a per-model key-generator wiring pattern (trait + config map of model → generator) to reimplement internally within a day.
- You're on a legacy Laravel version that predates
HasUuids/HasUlids and need a stopgap on one non-critical model.
- You're running a throwaway spike or internal prototype where dependency longevity genuinely doesn't matter.
Look elsewhere — specifically at framework-native features or a small in-house implementation — when any of the following hold:
- Maintenance confidence is unverified. Last release November 2022, 6 stars, 0 dependents, single-maintainer history, no visible security policy. Assume stale Composer constraints until proven in a scratch branch against your Laravel/PHP matrix.
- Supply-chain and ownership risk matter. Key generation is a correctness-critical failure domain (duplicate keys under concurrency or bulk inserts, column/index/collation mismatches, trait or model-event conflicts silently altering the lifecycle). Zero dependents means almost no community-reported edge cases to lean on. For a long-lived or regulated codebase, you're trading an unmaintained dependency for ~100 lines you own — a poor trade.
- Native equivalents already cover it. Primary keys →
HasUuids/HasUlids. API credentials → Sanctum/Passport. Both maintained, free, and covered by the framework you already pay for.
- You need a real credential system (rotation, revocation, scopes, expiry, audit logging) or idempotency keys — superficially similar, entirely different guarantees.
- You need to migrate existing tables. Backfilling and dual-writing are the actual cost, and no key-generation package solves them.
How to Pitch It (Stakeholders)
To executives: We evaluated a small open-source helper for generating Eloquent model keys. Recommendation: do not adopt it as a dependency. It is a six-star, single-maintainer library last updated in 2022 with zero downstream users, and the capability is already covered natively — Laravel ships ULID/UUID model keys and Sanctum/Passport for API credentials at zero added cost. The valuable output is the design pattern it demonstrates, which de-risks a decision we do need to make: standardizing one documented identifier strategy across our Laravel services, moving customer-visible IDs off sequential integers. Cost of acting is roughly one engineer-day per new service to wire up the framework default, plus a separately scoped estimate if we ever retrofit existing tables. The decision that matters is the standard, not the package.
To engineering: Treat juststeveking/laravel-key-factory as documented prior art, not a composer.json entry. First confirm which problem we have — model primary keys or API credentials — because the package has been read both ways and the answers diverge. For primary keys, adopt native HasUlids/HasUuids as the default for new externally-visible models, and confirm the migration column type and index assumptions before writing anything. For credentials, adopt Sanctum's token model. If we genuinely need per-model key strategy beyond the framework default, write a ~100-line first-party generator behind an internal interface so the format stays a one-line change, and test uniqueness under concurrency, bulk inserts, retries, and queue fan-out before rollout. Pin and document ownership for any exception, and record the call in an ADR so teams stop solving identity strategy individually. If we ever do take the dependency, a fork under our namespace is the more sustainable operating model than relying on upstream patches.