Laravel Menu Laravel Package

Product Decisions This Supports

• Feature enablement: Release 3.1.2 makes the package's $fillable attributes public, which means host applications and downstream packages can now inspect, extend, or override mass-assignment configuration at runtime without subclassing or reflection. This directly supports features like admin-editable field schemas, per-tenant model customization, and plugin/extensibility surfaces.
• Build vs. buy: If the roadmap includes configurable data models, multi-tenant settings, or user-defined forms, this package now covers the mass-assignment plumbing that would otherwise be custom-built and maintained in-house. That tilts the decision toward buy/adopt.
• Roadmap sequencing: Because the change is a patch-level (3.1.2) visibility widening, it is low-risk to adopt now. It unblocks extensibility-dependent work without forcing a major-version migration cycle.
• Use cases to prioritize: dynamic form builders, tenant-specific field configuration, integration adapters that need to map external payloads onto models, and internal admin tooling where operators adjust persistable fields.
• Risk posture: Widening protected to public is backward compatible for consumers; the main governance question is whether the package will treat this configuration surface as a stable contract going forward. Flag that expectation with the maintainer or pin the minor version.

When to Consider This Package

Consider adoption when:

• You need to alter or read fillable attributes from outside the owning class (service providers, config-driven bootstrapping, tenant resolution, or extension packages).
• You are building extensibility or admin-configuration features and want to avoid forking the package or writing reflection-based workarounds.
• You want a maintained Laravel-native solution rather than bespoke mass-assignment logic.
• Your team values patch-level, non-breaking upgrades and can absorb a 3.1.x bump with standard regression testing.

Look elsewhere or defer when:

• Your architecture deliberately restricts mass assignment to explicit DTOs, form requests, or validation layers—public fillable attributes can undermine that discipline if misused.
• You require a formally guaranteed public API contract; a patch-release visibility change is a signal that the package's configuration surface is still evolving.
• The only capability you need is this single behavior, which is trivial to replicate locally without a dependency.
• Package maintenance activity, security posture, or Laravel version support is unclear—validate before committing it to a customer-facing roadmap.

How to Pitch It (Stakeholders)

For executives: A small, low-risk upgrade to a Laravel package we are evaluating. It opens up configuration that previously required custom code, which reduces engineering effort for planned customization and multi-tenant features. No migration or breaking-change cost; recommend a time-boxed pilot rather than a broad rollout.

For engineering: Version 3.1.2 exposes fillable attributes publicly, removing the need for subclassing or reflection when dynamically configuring mass assignment. Visibility widening is backward compatible, but we should (1) treat the public surface as an implicit contract and pin the minor version, (2) add guardrails so public fillable configuration is not abused to bypass validation, and (3) cover the new surface with tests in any feature that depends on runtime field configuration. Recommendation: adopt for the extensibility use case, with version pinning and a short spike to confirm behavior under our tenancy model.