velitsol/userstamps
Velitsol Userstamps automatically records who created, updated, or deleted each Eloquent model, adding created_by, updated_by, and deleted_by columns without extra code. A lightweight Laravel trait for simple, reliable user attribution across your application.
Architecture fit. velitsol/userstamps is a narrow, single-responsibility package: one Eloquent trait that hooks creating/updating/deleting model events to stamp created_by, updated_by, and deleted_by from the authenticated user. Architecturally that is a good fit for a Laravel monolith or modular monolith that already uses Eloquent as its write path. It is a poor fit for anything that writes through query builders, upsert(), raw SQL, jobs, or event-sourced paths, because Eloquent model events do not fire there and the stamps will silently stay stale. Treat it as "last-toucher blame metadata," not an audit trail — it records who most recently changed a row, not a history of changes.
Integration feasibility. Mechanically easy: composer require, add three nullable columns per table, add the trait to each model (or to a shared BaseModel). The real cost is not the package but the schema work — column additions, backfills, and decisions about foreign keys and nullability across every table you want stamped. At 33 stars, 0 dependents, and an archived repository, there is no evidence of production use at scale and no compatibility guarantee for Laravel 9/10/11/12. Expect the composer constraint to reference Illuminate 5.x/6.x and to require a fork or repositories override to install on a current stack.
Technical risk. High for a 200-line convenience feature:
SoftDeletes, observers, and activity-log packages is undefined and can produce surprising deleted_by results.null or a NOT NULL violation depending on schema; writes outside Eloquent bypass the trait entirely.nullOnDelete, which destroys the blame data you added the package for.Key questions. Which Laravel and PHP versions must be supported? Does it support UUID/ULID primary keys and non-integer user keys? Does it no-op or throw when Auth::check() is false? How does it interact with SoftDeletes and with restoring? Is there a test suite, CI, and a stated license? Does it handle forceDelete separately? And critically: is a 50-line trait in a BaseModel — which you would own and could test — cheaper over three years than adopting an archived dependency?
Recommendation. Do not take a runtime dependency on this package. Use it as a reference implementation and vendor an equivalent trait into your own codebase, or evaluate wildside/userstamps (maintained, comparable feature set) if you want a supported dependency.
Stack fit. Appropriate for a conventional Laravel app on Eloquent with session-based or token-based auth where a "current user" is reliably resolvable during web requests. It is the wrong tool if your write path includes high-volume ingestion, queue-driven mutations, or service-to-service calls where the acting principal is not Auth::user(). In those cases the stamp should come from an explicit actor argument, not an ambient auth facade.
Migration path. Because the upstream is archived, the integration path is a fork-and-own, not a composer require:
app/Models/Concerns/Userstampable.php (MIT/license permitting — verify first) and add a composer.json note pinning provenance and the upstream commit SHA.created_by / updated_by / deleted_by columns via a single reusable migration stub, applied per table; use unsignedBigInteger (or the project's user key type) with an index, and nullOnDelete() on the FK unless compliance requires retaining IDs after user deletion.BaseModel rather than to individual models, so coverage is opt-out rather than opt-in and new models inherit it by default.YYYY-MM-DD" semantic — do not fabricate values.Compatibility. Confirm the fork runs on your Laravel version by exercising the trait-boot path, not just installation. Explicitly test: soft delete and restore, forceDelete, firstOrCreate/updateOrCreate, upsert, chunked mass updates, and console/queue contexts with no authenticated user. Decide policy per case — most teams should stamp on creating, updating, deleting, and restoring (clearing deleted_by on restore), and explicitly accept that bulk query-builder writes will not stamp.
Sequencing. Ship in four increments: (1) spike the trait on one low-risk model and validate event ordering against existing observers and activity logging; (2) resolve the unauthenticated-context policy (null vs. system-user sentinel) and encode it as a test; (3) roll out to the tables where blame data has a named consumer — approvals, financial records, config changes — not "all tables"; (4) add a lint/CI check or model test that fails if a new model in scope lacks the trait. Defer any table where the write volume is high and the blame value is speculative.
Maintenance. The package is archived, so the maintenance burden is fully internal from adoption: roughly 100–300 lines you now own, plus a standing obligation to re-verify it at every Laravel major upgrade. That is small but non-zero, and it competes with higher-value upgrade work. Budget an owner and a review at each framework bump; without one, the trait quietly becomes a blocker during a forced upgrade.
Support. No vendor support, no issue triage, 33 stars means Stack Overflow coverage is effectively nil. Debugging falls to reading the source, which is feasible at this size — an argument for the vendored fork, where you can add logging and tests, over an unmodifiable dependency.
Scaling. Per-write overhead is a single column update, negligible in CPU terms. The real scaling cost is index write amplification: adding an indexed updated_by to a high-write table widens every update and inflates the write-ahead log. On hot tables, decide whether the column must be indexed at all; often only created_by is queried by dashboard or support tooling. Reporting queries on created_by ranges will need composite indexes once tables reach tens of millions of rows.
Failure modes. The dangerous ones are silent, not loud:
Model::where(...)->update(...), upsert, and raw SQL produce rows with missing or stale stamps, which is worse than no column because it implies false provenance. Restrict or audit bulk-write paths.Auth user; without an explicit system-actor convention, created_by is null and blame is lost exactly where automated changes are most likely.deleting observer that runs before the trait sees a different state than one that runs after; add a regression test rather than reasoning about it.deleted_by persisting after a restore is a common and confusing bug.Ramp-up. Engineering ramp-up is low — a Laravel developer understands the trait in minutes — but organizational ramp-up is the risk: every developer must internalize that the stamps are best-effort and event-dependent. Without a one-page internal standard stating which tables are stamped, how unauthenticated writes are attributed, and which write paths bypass stamping, downstream consumers will over-trust the columns. Pair the rollout with a short doc and a test template; that documentation is a larger deliverable than the code integration itself.
How can I help you explore Laravel packages today?