Filakit Laravel Package

Technical Evaluation

Architecture fit Filakit is a Filament 3.x application starter/plugin scaffold from a single maintainer (jeffersongoncalves). It sits at the layer above Filament: it supplies auth flows (login), Eloquent models, and Filament resources, plus opinionated frontend/CI tooling. Fit is good if we are standardizing on Filament 3 for admin panels and want an opinionated head start; poor if we intend to hand-roll auth and panels, since the package's value is precisely the pre-wired conventions we would discard.

The 3.3.56 release is dominated by dependency and CI hygiene (Dependabot bumps across composer, npm, and GitHub Actions; workflow standardization; pnpm overrides relocated to pnpm-workspace.yaml with shell-quote and source-map-js patches; PHPStan now runs on PHP 8.4). None of that changes the architecture. One change does: PR #197, "Use user/admin packages for models, resources and login." This moves the package's own model/resource/login implementations onto external user/admin packages, converting previously self-contained scaffolding into a composition of additional first-party dependencies. That is a structural change to the dependency graph and to what we actually inherit.

Integration feasibility Feasible for a greenfield Filament 3 project. Two practical frictions:

1. Versioning is upstream-coupled. The tag 3.3.56 tracks Filament's version, not the package's own change surface. Semver signals we normally rely on are unavailable; a patch-level bump can carry a structural change like #197. Feasibility therefore depends on us diffing releases rather than reading version numbers.
2. Dependency depth increases with #197. We now inherit user and admin packages, each with their own release cadence, PHP constraints, and Filament compatibility windows. Our composer lockfile becomes a three-body problem.

Technical risk

• Medium-high: #197 has no migration note, no deprecation path, and no upgrade guide in the release notes. Existing installs that published or overrode Models/User, Models/Admin, or the login page will not automatically pick up the new wiring, and overrides of now-relocated classes will silently drift from upstream.
• Medium: maintainer concentration — nearly all commits and all CI changes are by one author. Bus factor is effectively one.
• Low-medium: PHP 8.4 is now exercised by static analysis but the notes do not state a supported PHP matrix or a minimum Filament constraint; worth confirming before we commit to a runtime.
• Low: the frontend patches (shell-quote, source-map-js via pnpm override) are build-time only, but they signal unpinned transitive advisories in the toolchain.
• Signal quality risk: roughly 20 of 24 PRs are automated dependency bumps and funding/CI churn. Release notes are therefore a weak changelog; the two substantive items (#197, pnpm overrides) required reading the PR titles to find.

Key questions

1. Does #197 require a migration for existing applications, and is there a documented upgrade path from 3.3.55?
2. What are the declared composer.json constraints for filament/filament, PHP, and the new user/admin packages? Is there a supported-version matrix?
3. Do the user/admin packages belong to the same maintainer, and are they at 1.0 / stable, or pre-release?
4. Can we override models and the login page without forking, after #197?
5. What is the intended support window per Filament minor, and how quickly does the package track upstream?
6. Is there a security disclosure channel, and does the package have any advisory history?

Integration Approach

Stack fit Assumes Laravel with Filament 3, Vite for asset builds, and (per the release notes) pnpm as the JS package manager. Our team must be on pnpm-capable tooling — the pnpm-workspace.yaml overrides change means npm/yarn consumers do not inherit the shell-quote / source-map-js patches. If our monorepo standardizes on npm, we must replicate those overrides manually or accept the transitive exposure.

Migration path No prior assessment exists, so there is no incumbent version to migrate from — we would adopt 3.3.56 directly, which is the cleanest possible entry point. Adopt after #197 rather than before; entering at 3.3.55 would put us immediately behind a structural change with no guide. For the models/resources/login surface, treat the package as a reference implementation rather than a black box: publish the config and stubs into our app, then own them locally. This converts the #197 risk from a live upgrade hazard into a one-time read-and-adopt decision.

Compatibility Pin Filament to a tested minor and pin filakit to an exact patch (e.g. 3.3.56, not ^3.3). Because filakit's version mirrors Filament's, a ^ constraint can pull a filakit patch that assumes a newer Filament than we run, or vice versa. Lock both together and upgrade them as a single unit. Confirm PHP support (8.4 is statically analyzed; verify runtime and CI matrix), and verify the user/admin packages resolve cleanly against our Laravel version.

Sequencing

1. Spike: install 3.3.56 in a throwaway Filament 3 app; diff generated models, resources, and login against 3.3.55 to characterize the #197 delta precisely.
2. Inventory the new user/admin dependency tree — versions, maintainers, licenses, advisory status.
3. Decide the ownership boundary: consume the package as-is, or publish and localize the model/resource/login layer.
4. Replicate the pnpm overrides in our own workspace config if we are not on pnpm.
5. Add a release-watch step: on each filakit tag, read the PR list, not the version number.
6. Pilot in one internal admin panel before wider rollout.

Operational Impact

Maintenance Ongoing cost is dominated by dependency churn, not by our own code. Releases land frequently and are mostly bumps; each one is a small but non-zero review. Budget roughly a recurring half-day per release cycle for diff review and lockfile reconciliation, plus a larger one-off for #197. Because version numbers track Filament, our upgrade calendar is effectively set by upstream Filament, not by us — plan Filament minor upgrades as the forcing function.

Support Single-maintainer project with no vendor backing and no visible SLA. Community support only. We should not plan to file issues and wait; assume we can patch locally. This argues strongly for localizing the model/resource/login layer so we are not blocked on upstream for routine fixes. Internally, designate one owner for this dependency and document it as such.

Scaling Runtime scaling is a non-issue: this is scaffolding and admin UI, not an infrastructure component, and nothing in 3.3.56 touches request-path behavior. The scaling concern is organizational — the number of transitive dependencies we now inherit (#197 plus composer-deps bumps to 4 and 3 packages across separate PRs) grows our audit and patch surface roughly linearly with adoption breadth.

Failure modes

• Silent override drift: local overrides of model/resource/login classes stop tracking upstream after #197, producing bugs that appear only on the next upgrade. Mitigate with a documented override list and a diff check in CI.
• Version skew: ^3.3 constraint resolves a filakit patch expecting a Filament version we do not run. Mitigate with exact pinning and paired upgrades.
• Abandonment: single maintainer stops shipping; we are stranded on a Filament minor. Mitigated by maintaining a fork-ready posture (localized stubs, no deep inheritance from package internals).
• Toolchain divergence: npm-based consumers miss the pnpm-only security patches. Mitigate by porting overrides.
• Missed structural change: a patch bump carries a breaking change we did not read (#197 is the precedent). Mitigate by treating every tag as potentially breaking and reviewing the PR list.

Ramp-up Low for engineers already fluent in Filament 3 — a day to install, diff, and localize. Non-trivial for the TPM function: the release notes are not a reliable change record, so estimating upgrade effort requires reading PR titles and diffs directly. Build that review step into the process from the start rather than discovering it on the first surprise patch bump.