Base Laravel Package

Technical Evaluation

Architecture fit. The first thing a TPM must internalize: this is not a package in the dependency sense. filakitphp/base is a forkable application starter — a Laravel app skeleton with a pre-wired Filament v3 admin panel, user model, auth, base resource/page/widget classes, tests, PHPStan, and GitHub Actions. You cannot composer require it and get value; the value only exists if you treat it as a template snapshot you clone once and own. That reframes the decision from "should we depend on this?" to "should we start our next internal tool from this scaffold or from a blank laravel new?" The underlying framework surface (Filament v3.3.56, Livewire, Tailwind) is the real architecture bet; this repo is just a curated arrangement of it.

Integration feasibility. High friction only in one direction: greenfield. Retrofit into an existing Laravel app is effectively a manual port of user/auth wiring and tooling conventions — usually not worth it, since installing Filament into a plain Laravel app is cleaner. There is no published API, no service provider contract, no semver guarantee for your consumption surface.

Technical risk. Elevated relative to the stated maturity and worth stating plainly to stakeholders:

• Signal is thin. 2 stars, composite score ~19/100. Treat every claim in the description as unverified until you read the diff.
• Documentation drift is already visible. The description claims "Laravel 13.x"; no such release exists, and the release notes reference filakitphp/basev3 PRs while the canonical repo is /base. That mismatch suggests docs are generated or copied rather than maintained, and it undermines the changelog as a trustworthy artifact.
• Version numbers are not your contract. 3.3.56 mirrors Filament's tag, not a semver promise. "Patch" releases here have contained behavioral changes (the filament-user auth swap).
• Bus factor of one. A single maintainer authored the bulk of recent PRs and is still listed as a "new contributor" — a review-process smell.
• Toolchain churn. Frontend builds moved pnpm → bun. That is a team-wide developer-environment commitment dressed as a dependency bump.

Key questions.

• Is this a fork-and-own template or a tracked upstream? (Recommendation: fork-and-own, with a named internal owner.)
• Does filament-user — now the source of user model, user resource, and login — meet our auth, policy, and SSO requirements, and what is its own support posture?
• Is bun mandatory or is pnpm still viable? Is pnpm-lock.yaml retained?
• Is PHP 8.4 a tested target or only a PHPStan lint target?
• What PHP/Laravel/Filament matrix does CI actually cover, and are Dependabot bumps auto-merged?
• Who owns the scaffold when we have 5–10 internal tools forked from it?

Integration Approach

Stack fit. Assumes Laravel (11/12, per the actual code — not "13.x"), PHP 8.3/8.4, Filament v3.3.56, Livewire + Tailwind, bun for assets, GitHub Actions for CI. Teams standardized on pnpm, or with Dockerfiles and Vite configs hardcoded to pnpm scripts, should treat the tooling migration as the primary integration workstream rather than a footnote.

Migration path. Do not rebase a production fork onto this tag blindly. Sequence:

1. Pin existing forks to 3.3.55.
2. Diff in a scratch branch, specifically: composer.json, package.json, lockfiles, .github/workflows/*, dependabot.yml, and app/Models/User.php + app/Filament/**/UserResource.php + the login page.
3. Cherry-pick the low-risk dependency bumps — these are independently valuable and separable from the auth change.
4. Adopt bun only as a deliberate, documented environment change with CI runners, Docker base images, and onboarding docs updated in the same PR.
5. Evaluate filament-user separately, with its own ADR. This is the highest-blast-radius item in the release — it moves the auth boundary into a third-party package.

Compatibility. No stated PHP/Laravel floor change, but the Filament pin at 3.3.56 means every Filament plugin in your tree must be compatible with that exact tag — verify before the bump, not after. Bun requires a modern Node runtime on every dev machine and CI image; this is the most likely source of "works on my machine" divergence. Confirm filament-user supports your Laravel and Filament versions before committing.

Sequencing. Week 1: pin, diff, cherry-pick dependency bumps, run a plugin-compatibility check against Filament 3.3.56. Week 2: stand up the standardized tests workflow; run PHPStan on 8.4 against our code, not the base's. Week 3: pilot bun in one non-critical environment with a documented rollback to pnpm. Week 4+: decide on filament-user, then update onboarding docs and CI templates before rolling to the team. Budget realistically: the "day to clone and trim" pitch is accurate for scaffolding; the surrounding governance and environment work is a multi-week program.

Operational Impact

Maintenance. Dependency-only releases are cheap to consume but set a treadmill: this single tag carries ~14 Dependabot PRs. Expect a 3.3.x roughly in step with Filament patch cadence — a low-effort, high-frequency rhythm rather than rare large upgrades. Assign one named maintainer to the fork and to the pin/port decision; without that, forks drift and scaffold diffs grow unbounded across projects.

Support. Upstream support is effectively Filament's, plus a thin veneer. Assume self-support for anything outside core Filament. Because maintainer concentration is high, do not build an escalation path that depends on the upstream repo; your internal owner is the support model. Cost this as internal engineering time, not a vendor line item.

Scaling. Runtime scaling is a non-issue — characteristics are those of your app and Filament. The real scaling axis is team and portfolio scale: the more internal tools forked from this base, the more expensive each scaffold-level change becomes. The filament-user swap is the template for that cost: one decision, N repos, N auth regressions to test. Standardizing on "pin + selectively port" keeps that cost linear instead of multiplicative, and makes the base a genuine platform play rather than copy-paste sprawl.

Failure modes and mitigations.

• Stale lockfile after bun migration → non-reproducible asset builds. Mitigate: commit and assert lockfiles in CI.
• filament-user collides with existing auth/policies → login and authorization regressions in the least-tested part of most admin panels. Mitigate: auth smoke tests before and after the decision.
• Filament 3.3.56 conflicts with a pinned plugin → panel breaks at runtime while CI stays green. Mitigate: plugin-compatibility gate on the Filament bump.
• Auto-merged Dependabot bumps → unreviewed transitive changes. Mitigate: require human review on Composer group PRs.
• PHPStan-on-8.4 false confidence → mistaken belief the app is 8.4-ready. Mitigate: treat as lint signal only; add an explicit 8.4 test matrix run if 8.4 is a target.

Ramp-up. Low for any team already on Laravel + Filament; the scaffold is conventional and readable. The non-obvious onboarding costs are (a) bun, which changes local setup instructions, and (b) the fact that contributors must understand they are editing a fork, not consuming a library — there is no upgrade command to lean on. Write that down before the second project forks it.