Laravel Activatable Laravel Package

Technical Evaluation

Architecture fit — laravel-activatable is a conventional Eloquent behaviour package: a trait applied to models, query scopes for filtering active/inactive records, and publishable migrations that add activation state columns. This is the standard Laravel extension pattern (trait + scope + service provider with package auto-discovery), so it slots into an existing domain layer without requiring an architectural change. It is additive, not invasive: no base model replacement, no container rebinding, no middleware.

Integration feasibility — Low. Typical adoption is composer require, publish migrations, php artisan migrate, then use Activatable on target models. Effort is measured in hours per model, dominated by the data backfill decision rather than the code change.

Technical risk — Moderate, and mostly unverified rather than known-bad. The 1.0.0 release notes contain only a changelog link with no substance, so this assessment is inferred from the package's name, namespace (bernskiold) and Laravel ecosystem conventions, not from a reviewed diff. Specific unknowns: the supported Laravel/PHP version matrix, whether the trait stores state as a nullable timestamp, a boolean, or both; whether it emits events on activation/deactivation; test coverage and CI; and whether migrations are reversible. The 1.0.0 label is a stability signal for the API surface but says nothing about maturity of the maintainer's release process.

Key questions for the maintainer / spike

• Which Laravel and PHP versions are supported, and is the constraint tested in CI?
• What is the persisted schema — nullable activated_at, boolean flag, or status enum? Is "never activated" distinguishable from "deactivated"?
• How does it interact with SoftDeletes, existing is_active columns, and global scopes?
• Are activation/deactivation performed via model methods (event-firing) or query builder mass updates (bypassing events and observers)?
• Are the published migrations reversible without data loss, and are the state columns indexed by default?
• Does it enforce mass-assignment protection on the state attributes?
• Licence, maintainer count, open-issue count, last commit date.

Treat the absence of a real changelog at a 1.0.0 milestone as a process signal. It is not disqualifying for a package this small, but it means the source must be read before adoption.

Integration Approach

Stack fit — Assumes a Laravel application on Eloquent with standard migration-driven schema management. No frontend, queue, or cache surface. It composes cleanly with authorisation policies (gate access on activation state) and with admin/filament-style back offices, but the package supplies only the model layer — UI and permission semantics remain ours.

Migration path — Install behind a feature branch, publish the migrations, and inspect the generated schema before running anything against a shared database. Add the state columns as nullable, deploy the schema change independently of the code change, backfill existing rows to a deliberate default (usually "active"), then apply the trait to a single low-traffic model. Only after that pilot passes the full suite do we expand to further models.

Compatibility checks

• Pin the exact version in composer.json; do not float ^1.0 until the release cadence is understood.
• Verify the package's Laravel constraint against our framework version rather than assuming auto-discovery resolves it.
• Confirm behaviour on our specific driver (MySQL/Postgres/SQLite) — nullable timestamp comparisons and timezone handling differ.
• Check for column-name collisions with any existing active/activated_at fields, and for interaction with SoftDeletes on the same model.

Sequencing

1. Read the source (small package — a few files) and the test suite; capture findings in the ADR.
2. Pin version, install on branch, review generated migrations.
3. Ship schema + backfill as one deploy; ship trait adoption as a follow-up deploy.
4. Pilot on one model, add regression tests covering active/inactive scopes and the deactivate→reactivate round trip.
5. Roll forward to remaining models only after the pilot survives a release cycle.

Operational Impact

Maintenance — Single-maintainer, low-volume package. The realistic maintenance task is not patching but watching: track upstream commits and be prepared to fork, since a one-person project may lag on new Laravel majors. Budget a recurring review each framework upgrade.

Support — Community support via GitHub issues only; no commercial backing, no SLA. Internal knowledge will reside with whoever performs the source read, so document the schema contract and trait semantics in-repo.

Scaling — Query cost is governed by whether the state columns are indexed. A scope compiling to where activated_at is not null is cheap with an index and a sequential scan without one; on large tables that is the difference between a fast page and an incident. Also verify that any global scope does not silently reshape analytics or reporting queries, where "inactive" rows can legitimately matter.

Failure modes

• Silent no-op: scope called on a model missing the trait, or trait applied without the columns migrated — queries return everything or error late.
• State ambiguity: nullable timestamps conflating "never activated" with "deactivated", producing bad reports.
• Event bypass: bulk update() changing state without firing observers, so audit logs and downstream jobs drift.
• Backfill mistakes: defaulting existing rows to inactive, locking users out at deploy.
• Rollback data loss: migrate:rollback dropping state columns and destroying activation history.
• Timezone drift: activation timestamps written in app timezone, compared in UTC.

Ramp-up — Low for anyone fluent in Eloquent: roughly half a day to read the source and ship a pilot. The non-obvious cost is the data decision — which records count as active on day one — and that conversation belongs to the product owner, not the developer.