Forms Laravel Package

Technical Evaluation

Verdict: Conditional / Low-priority — unchanged in substance, marginally improved on one axis. v6.0.0 is the first release signal in roughly three years and is the only new data point available. It partially addresses blocker #1 (stale release line) and does nothing for blockers #2 (zero ecosystem dependents) and #3 (NOASSERTION license). A single release is evidence of activity, not evidence of a maintenance cadence, and the release note — "Bootstrap 5 compatibility and more" — is content-free: no changelog, no upgrade guide, no linked diff. A major version bump whose contents are described as "and more" is a breaking-change signal we cannot scope. The verdict does not move to adopt; it moves from "likely abandoned" to "possibly revived, unverified."

Architecture fit

• Unchanged at the core: server-rendered, class-based form abstraction for Blade, delegating markup to grafite/builder. Still fits Laravel monoliths and admin panels; still poor fit for API-first, SPA, Inertia, or Livewire-fronted applications where HTML rendering, old-input repopulation, and error display carry no value.
• New fit constraint: styling. "Bootstrap 5 compatibility" implies the package's rendering layer is now oriented to Bootstrap 5 markup and class names. If our design system is Tailwind, Bootstrap 4, or a bespoke component library, v6 either pushes us further from fit or forces us to override the builder's templates — which re-introduces the coupling risk in the one area (markup) the package exists to own.
• The opinionated inheritance model (form classes extending a package base class) is unchanged. That remains a control-inversion decision, not just a dependency decision.

Integration feasibility

• Install friction is still low (composer require grafite/forms, auto-discovery, publishable config), but the version matrix question is now sharper and less answerable from public information than before. The Feb-2022 line targeted Laravel 8/9; v6.0.0 may target Laravel 11/12, or may have been cut as a markup-only change on an older framework floor. We do not know, and the release note does not say.
• grafite/builder remains a non-separable transitive dependency. A major bump to forms almost certainly pins a new builder floor — that pairing must be resolved before any estimate.
• Feasibility is now a two-part proof: (a) does v6.0.0 boot on our Laravel/PHP combination, and (b) what did "and more" break relative to v5.

Technical risk

• Maintenance abandonment (downgraded high → medium-high). One release breaks the abandonment thesis but does not establish responsiveness. The discriminating test is whether a v6.0.1 / issue-tracker reply appears within a reasonable window of 6.0.0.
• Undocumented breaking changes (new, medium-high). Semver major + "and more" = unknown surface. Any team currently on v5 has an unscoped upgrade; any new adopter inherits a version whose delta is unread.
• License ambiguity (high, blocking, unchanged). NOASSERTION still means automated scanning cannot clear it. A new release does not change the LICENSE file's provenance. Enterprise distribution or SaaS use still requires explicit legal sign-off. This remains the hard gate.
• Ecosystem isolation (medium-high, unchanged). Zero dependents. A first release in three years with no downstream consumers means v6.0.0 is field-untested by anyone but its maintainer. We would again be the earliest adopter.
• Markup churn (new, medium). Bootstrap 5 alignment means rendered HTML differs from prior versions. Any existing theme overrides, view publishing, or snapshot tests are invalidated.
• Hidden coupling (medium, unchanged). Custom field types, macros, and rendering overrides still require learning and extending grafite/builder.
• Security review (medium, unchanged). Field rendering, raw HTML attributes, and mass-assignment paths still require an XSS and authorization audit — arguably more so now that the markup layer changed.

Key questions

1. What exactly is in "and more"? Is there a CHANGELOG, an UPGRADE guide, or a v5→v6 diff we can read?
2. Which Laravel and PHP versions does v6.0.0 actually support, and does it boot cleanly on our current Laravel major with config:cache enabled?
3. Which grafite/builder version does v6.0.0 require, and what changed there?
4. Is Bootstrap 5 markup mandatory, or themeable? What is the override path if we are not on Bootstrap 5?
5. What is the license, in writing, and has it changed in this release?
6. Does the maintainer evidence any ongoing commitment — a roadmap, a response on issues, a follow-up patch — or is 6.0.0 a one-off?
7. Does v6 handle our real form complexity (repeatable/nested fieldsets, conditional visibility, multi-step wizards, file uploads, polymorphic binding), or does each become a custom extension?
8. If v6.0.0 is the last release for another three years, what is our fork-and-own cost, and who absorbs it?

Integration Approach

Stack fit

• Still recommended only for internal, low-blast-radius admin CRUD in a Blade-rendered Laravel app — and now additionally conditional on being a Bootstrap 5 front end, or on accepting the cost of overriding the rendering layer.
• Still not recommended for customer-facing, regulated, or revenue-path forms.
• If the team is standardized on Inertia/Livewire/API-first, reject on architecture grounds regardless of the v6 release or license outcome. Nothing in this release changes that.

Migration path

• Treat v6.0.0 as a re-evaluation, not an upgrade. The prior 2022 line is no longer the decision object; the matrix and spike must be re-run against 6.0.0 specifically.
• Greenfield-only adoption still holds. Retrofitting an existing form set into package form classes remains a rewrite with no incremental delivery.
• Exit path remains comparatively clean (declarative PHP form classes port mechanically to Blade components or Form Requests). Keep the containment rule: wrap every package form behind an internal interface so call sites never reference Grafite\Forms\* directly.

Compatibility

• Gate on a proven matrix against v6.0.0, not a README claim and not inference from the release title. Test: install with the paired builder version, publish config, config:cache, define one form with validation and a file upload, render, submit, repopulate after validation failure, and assert the emitted markup on our exact Laravel/PHP combination.
• Diff the rendered output against Bootstrap 5 expectations and against whatever our design system emits. If we are not on Bootstrap 5, this is where the package fails or where override cost becomes visible.
• Re-verify interaction with our Form Request and Policy/Gate conventions, and re-check facade alias, Blade directive, and macro namespace collisions.

Sequencing

1. Legal: resolve NOASSERTION. Hard gate, unchanged, no engineering time before it closes.
2. Read the v6.0.0 changelog/diff. If none exists, that absence is itself the finding — record it and proceed with elevated caution.
3. Timeboxed spike (≤3 dev-days) against v6.0.0: version matrix, config cache, two representative forms, markup diff, security read of rendering and mass-assignment paths.
4. Comparative baseline: build the same two forms with native Blade components; measure LOC, time-to-first-form, time-to-change-a-field.
5. Decision gate: adopt only if the package wins on measured effort and the fork-ownership cost has a named accountable owner.
6. If adopted: pilot one internal admin form behind the internal abstraction for one release cycle, with an explicit re-evaluation date.
7. Expansion only after the pilot survives one Laravel patch upgrade without intervention.

Operational Impact

Maintenance

• Posture remains "we own a fork," but the clock resets: pin to v6.x, patch Laravel compatibility ourselves, re-evaluate on a schedule. Budget unchanged.
• Update the watchlist trigger. Replace "12 months without an upstream release" with a sharper test now that a release has landed: if v6.0.0 is not followed by a patch or issue-tracker response within two quarters, revert to the abandoned assumption. That distinguishes a revived project from a single maintenance burst.
• Track the grafite/builder pairing as part of the same watch item — it moves with the parent.

Support

• Still no vendor, no SLA, no commercial backing. The v6 release is a positive signal about intent, not about support capacity; a maintainer who ships a major with no changelog is not demonstrating operational rigor.
• Internal documentation of the form DSL and extension points remains mandatory, and now must be re-baselined for v6 markup.
• Escalation for a production rendering defect is still "we fix it." On-call must include someone able to read package internals.

Scaling

• Rendering cost remains negligible — server-side string assembly per request. No horizontal scaling concern.
• The binding constraint is still organizational: each new field type and each new team member multiplies the custom-extension surface. Cost scales with breadth of adoption, not traffic. A markup-layer change across a major version is a direct tax on exactly that surface.

Failure modes

• Undocumented breakage from "and more" — behavior changes not covered by the release note, discovered in our app rather than in a changelog.
• Silent HTML regression after v6 or a Laravel upgrade (renders, but wrong). Worse than a hard failure, because tests may not assert markup. Elevated risk now that the rendering layer is known to have changed.
• Stranded on v6.0.0 if this turns out to be a one-off release, leaving us pinned to a version with no patch path.
• Validation error display or old-input repopulation breaking on edge cases (file inputs, arrays, nested fields), producing data loss on failed submits.
• XSS exposure via unescaped field attributes or custom field types.
• Authorization bypass if package submit handling substitutes for Form Requests and Policies.
• Config-cache or facade-alias collision breaking unrelated app boot paths.
• Abandonment mid-adoption leaving a partially migrated form set split across two paradigms.

Ramp-up

• Unchanged and non-trivial: Laravel fluency does not transfer to Grafite's DSL plus grafite/builder. Documentation is thin and the community small enough that public troubleshooting help is effectively absent — and the v6 markup change makes existing third-party examples and blog posts partially stale.
• Estimate 1–2 days per developer to productive competency, borne entirely internally, with no external training material.
• Onboarding friction is permanent: every new hire must learn a package they will never encounter elsewhere. That remains a recurring tax on a low-visibility dependency with no dependents.