Laravel Menu Laravel Package

Technical Evaluation

Evidence confidence: low. The assessment below is anchored on a single line — Changed: Fillable attributes public — with no repository metadata, changelog history, download stats, or maintainer signals in the data set. Treat version constraints and framework compatibility as inferences from the 3.x major line and Laravel conventions, not verified facts. Re-validate against composer.json before any commitment.

Architecture fit. In Laravel, $fillable is a protected property on Illuminate\Database\Eloquent\Model, read via getFillable(). A package promoting its fillable attributes to public is signalling that the mass-assignment whitelist is an intended read surface — the pattern you see in model-metadata, scaffolding, admin-panel, and API-schema packages that enumerate fields to generate forms, validation rules, or OpenAPI definitions. That fits cleanly into the CRUD/scaffolding layer of a standard Laravel app and is a poor fit for anything requiring encapsulation or per-tenant field policy variation, where the whitelist must be computed at runtime rather than declared.

Integration feasibility. Low effort. Widening visibility is a strict superset: every existing consumer calling $model->getFillable() or reading the property via reflection continues to work unchanged. No service provider registration, config publishing, or migration is implied by the change.

Technical risk. Source-compatible and non-breaking in the language sense — visibility widening is LSP-safe and does not break subclasses. The risk is semantic, not syntactic:

• A public mutable array invites runtime mutation ($model->fillable[] = $request->input('field')), which silently defeats mass-assignment guarding. This is a well-known injection vector and the change makes the footgun easier to pick up.
• The mass-assignable field list becomes readable by any code holding an object handle — mild reconnaissance value, not a vulnerability on its own.
• Child classes that redeclare $fillable as protected will fatal on class load (visibility narrowing is illegal in PHP). This is the one concrete pre-merge check.

Key questions for the maintainer. Is public applied to every model or a single introspected class? Is it documented as a supported extension point, or incidental? Are there tests asserting fillable contents and stability? Is there a config flag to restore previous visibility? Does it duplicate or conflict with packages already reading fields via getFillable()/reflection? Is 3.1.2 the entry point for our tracking, or are there unreviewed 3.0/3.1 changes behind it?

Integration Approach

Stack fit. Assumes Laravel 9–11 on PHP 8.1+, consistent with an actively maintained 3.x line. Confirm the illuminate/* constraints and PHP floor from composer.json; do not schedule work until that is verified.

Migration path. Drop-in. Bump the constraint to ^3.1.2, run composer update, and clear caches in cached deploys (php artisan optimize:clear) so config/package discovery is not stale. No publish step, no schema change, no data backfill.

Compatibility. Run two checks before merge: (1) grep -rn 'protected \$fillable' across app models, vendor overrides, and any first-party subclass of the package's models — a narrowing redeclaration is a hard fatal; (2) a static analysis pass (Larastan/PHPStan), since a public property changes the type surface tooling sees and may surface new notices in consuming code.

Sequencing. Pin and install in a low-traffic environment → run the grep and static analysis → staging with a smoke test on any admin/scaffolding surface that renders fields → production. Because the change is additive in capability, it can ship independently of feature work; do not bundle it with an unrelated release where a fatal-on-load would be hard to bisect.

Operational Impact

Maintenance. Negligible. No new runtime surface, no added dependency weight, no background processes. The one thing to watch is a future release narrowing visibility back — that would be breaking for any internal tooling we build on top of it, so pin conservatively and read 3.2.0 notes closely.

Support. Low but non-zero. Expect "is public fillable safe?" questions from the team; pre-empt with a line in the internal changelog stating the intended read-only usage and the ban on runtime mutation. Support load rises only if teams adopt it as a dynamic-form mechanism without guardrails.

Scaling. No effect on throughput, query volume, or infrastructure. Reading the property is O(1); the change is metadata exposure, not a hot path.

Failure modes.

1. Subclass redeclares $fillable as protected → fatal error at class load, typically only on the code path that autoloads that model.
2. Runtime fillable mutation → mass-assignment bypass, presenting as silent data corruption or privilege escalation rather than an exception.
3. Tooling that snapshots the fillable list at boot caches a stale schema after a deploy.
4. Auto-generated admin or API surfaces pick up newly declared columns and expose them without an explicit review gate.

Ramp-up. Effectively zero for existing Laravel developers. Budget roughly 30 minutes of team communication covering the intended use (introspection) and the single prohibition (never mutate fillable at runtime). No training, no new tooling.