Conditional Container Laravel Package

Technical Evaluation

Architecture fit. This is a narrow, presentation-layer utility for Laravel Nova resources, not application infrastructure. It ships a ConditionalContainer field wrapper plus a HasConditionalContainer trait; adoption is a trait import and a wrapper around existing field arrays in fields(). There is no service provider surface worth reasoning about, no migrations, no persistence, no API contract change. The architecture fit question for a TPM is therefore binary: are we on Nova, and does our form complexity justify a dependency? If either answer is no, the evaluation closes.

Integration feasibility. Low effort, high uncertainty. The install is one Composer require plus a trait; the first container is a 10-line diff. The uncertainty is entirely in version compatibility: last release is May 2022 (v1.4.3), against a Nova major that has moved since. A TPM should treat this as a pilot-with-abort-criteria decision, not a blanket adoption.

Technical risk. Three concentrated risks, all manageable if framed correctly:

1. Staleness vs. Nova major. The 2022-era dist/js/ against a current Nova is the highest-probability failure. Pin to 1.4.3, test the exact production matrix in staging, and budget a fork-and-patch allowance.
2. Documentation drift as a maintenance signal. The metadata contradicts itself — repo and release notes describe a Nova field; one blurb claims a Blade component with a Filament mention. That drift is itself evidence of the vendor-risk profile. Resolve from composer.json before sign-off.
3. Hidden ≠ absent. Visibility is UX, never access control or validation. Server-side rules and policies remain authoritative. This is a non-negotiable framing for any PM sign-off.

Key questions a TPM must answer before allocating a slot:

• Which framework and major version does composer.json actually target, and does it match our admin stack today?
• Do we have ≥ 6 meaningful field dependencies across our Nova resources, or are we adding a dependency for two forms?
• Is there a native Nova dependent-field equivalent that covers our top cases? If yes, why are we buying?
• Who owns the fork-and-patch path if Nova breaks this in the next upgrade? (Name a person, not a team.)
• Have we confirmed the closure signature for dependsOn against src/ConditionalContainer.php, not the README?

Integration Approach

Stack fit. Adopt only if (a) the admin stack is Nova, verified from composer.json, and (b) our resources show enough conditional-field duplication to justify a shared wrapper. The package is presentation-only: it does not touch validation, persistence, domain logic, or customer-facing surfaces. That containment is the primary reason this is a low-blast-radius bet — it makes the review and QA surface small and revertible.

Migration path. There is no migration — this is additive. The pattern is per-resource adoption:

1. Pick one internal, read-only resource (no customer consequence).
2. Add HasConditionalContainer to the resource; wire a single two-field dependency.
3. Extract reusable containers as private methods on the resource (billingContainer()) so the swap-out seam is one method per resource, not scattered.
4. Hold one sprint. Then replicate resource-by-resource, one PR each.

That "one method per resource" discipline is the migration path out as well — when native Nova logic or a fork replaces this, the edit is localized.

Compatibility. Pin 1.4.3 explicitly — do not float on ^1.4. Verify against the exact Nova/Laravel/PHP versions in production. Test create and update paths for every container shipped (v1.4.3's release note — "Check if field is shown on update" — is direct evidence that update-page visibility was a real bug). Include the closure-based dependsOn variant in the pilot; that is the API most likely to differ from assumptions.

Sequencing.

• Week 1: verify target framework and version; run the smoke test matrix (condition false on create, true on create, flip true on update, flip false on update) against a single internal resource.
• Week 2–3: hold. Add a line to the upgrade checklist: re-test every resource using conditional-container.
• Week 4+: expand one resource per PR, reviewed like any small diff.

Do not sequence this as a strategic initiative. It is a sprint-sized admin UX improvement with an hours-scale rollback. If the pilot reveals a Nova-major incompatibility, that is the end of the evaluation — not a reason to invest in a fork unless the use cases are demonstrably valuable.

Operational Impact

Maintenance. Near-zero until a Nova/PHP upgrade, at which point the lifecycle risk is concentrated entirely in that event. Do not schedule maintenance on a calendar cadence; schedule it against the Nova upgrade moment. Add the compatibility re-test to the upgrade checklist so it is not forgotten when the upgrade arrives.

Support. Single maintainer, zero dependents, last release 2022. This is not infrastructure; it is a utility. Frame it to stakeholders as contained, replaceable bet on a paid admin panel — not as a long-term platform commitment. The exit cost is hours, but only if someone on the team can read the field-rendering code. Identify that person during the pilot, not after a breakage.

Scaling. Zero runtime cost — admin UI only, off the request path. It does not affect API latency, database load, or customer experience. The scaling concern is not throughput; it is combinatorial QA surface: rules per container and nested containers (inside Repeater, Builder, nested containers) multiply field-instance state. Policy: prefer several small containers (one per state) over one container with a baroque multi-value condition; avoid nested containers unless tested; test every field type in the pilot, not just Text and Select.

Failure modes.

• Silent non-reactivity. Trait missing → container renders but never updates. Guard: reviewer checklist confirms HasConditionalContainer is applied.
• Update-path regression. Historical bug fixed in 1.4.3; earlier 1.4.x diverges between create and update. Guard: pin 1.4.3; test both paths.
• Field-order dependency. Controller field declared after the container → undefined value on first render. Guard: house rule — controllers above dependents, always.
• JS/asset collision. dist/js/ conflicting with other Nova packages. Guard: debug via dd($this->fields(request())) to separate server-side resolution from browser-side rendering.
• Validation bypass assumption. Team assumes hidden = not validated. Guard: explicit rules (required_if:…, sometimes), a feature test that submits condition-false with the dependent field populated, and a written statement in the PR description that visibility is not access control.

Ramp-up. Low for engineers familiar with Nova resources — the API is one wrapper and one trait. The real ramp-up is organizational: get the team to internalize three rules — controllers above dependents, several small containers over one large one, server-side validation always. Encode those in the resource template or a short internal note; they are the difference between a clean adoption and a slow accumulation of nested-container debugging.

PM-level decision framing. This package converts hand-rolled conditional-visibility glue into a declarative resource definition — an MIT-licensed, reversible bet that buys back engineering time on back-office admin. The decision is "spend hours to save hours, if the pilot proves compatibility" — not "invest in admin UX strategy." Adopt only when the framework match is verified, compatibility is proven in staging, behavior is non-critical, and a named owner can read the field-rendering code if the vendor path closes. Otherwise, close the evaluation in ten minutes.