Nativekitv4 Laravel Package

Technical Evaluation

Package: jeffersongoncalves/nativekitv4 — a Laravel + Filament v4 admin/application starter kit, not a runtime library.

Architecture fit. The package is an opinionated scaffold: it ships models (User/Admin), Filament resources, authentication scaffolding, and frontend tooling. Fit is strongest for greenfield, admin-panel-first Laravel applications where a team wants a working Filament v4 baseline on day one. It is a poor fit as a Composer dependency inside an existing application, because its value is in the file layout it generates, not in reusable runtime services. Teams expecting a package they can composer require and configure should look elsewhere.

Integration feasibility. Low friction for a fresh scaffold, higher friction for anything else. The 4.14.0 release is dominated by dependency and CI maintenance (Dependabot consolidation, PHPStan on PHP 8.4, pnpm workspace overrides, patched transitive npm packages shell-quote and source-map-js), which is straightforward hygiene. The one materially behavioral item is PR #95, "Use user/admin packages for models, resources and login" — this moves models, Filament resources, and login flows into separate user/admin packages. That is a namespace and file-structure change, not a bug fix, and it lands inside a minor version bump.

Technical risk. Moderate. Three vectors:

1. Structural change under a minor version. PR #95 changes where User/Admin models, resources, and auth live. Any fork built on 4.13.4 that cherry-picks or merges 4.14.0 will hit duplicate or relocated classes, broken imports, and potentially conflicting migrations. SemVer for a starter kit is advisory at best; treat 4.14.0 as a structural release.
2. Filament 4.14.0 alignment. The headline bump is a Filament minor. Filament minors have historically carried Livewire/Tailwind/asset-pipeline adjustments; the release notes do not restate Filament's own changelog, so that risk has to be assessed upstream.
3. Single-maintainer concentration. All non-bot PRs in this release are from one author. Release cadence is high and Dependabot-driven. That is fine for a template but means upgrade notes, deprecation paths, and backports are unlikely to exist unless explicitly written.

Positive signals worth crediting: static analysis is run on PHP 8.4, transitive npm vulnerabilities are being patched via pnpm overrides rather than ignored, and CI workflows are being standardized. That is a maintainer doing the unglamorous work.

Key questions to resolve before adoption:

• Is nativekitv4 consumed via create-project/template clone, or as a Composer dependency? The answer determines whether 4.14.0 is an upgrade or a re-scaffold.
• Does 4.14.0 ship upgrade notes or a migration path for the user/admin package split, or is the expectation "re-clone and re-apply your work"?
• What are the PHP and Filament version constraints in composer.json — ^4.14 or a pinned 4.14.0? Pinning reduces future breakage but blocks security patches.
• Does the pnpm-workspace.yaml move require existing forks to restructure their Node setup, or is it additive?
• Is there any stated support window, or is main the only supported branch?

Integration Approach

Stack fit. Laravel 11/12 + Filament v4 + Livewire + Tailwind, with pnpm for frontend assets and PHPStan for static analysis. This aligns cleanly with a standard modern Laravel shop. The pnpm workspace and override configuration means the frontend build is opinionated — teams on npm or Yarn will need to adapt, and the shell-quote / source-map-js overrides only take effect under pnpm.

Migration path from 4.13.4. Do not merge. The user/admin package split makes 4.14.0 a re-baseline, not a patch. The practical options are:

1. Re-scaffold and port — generate a clean 4.14.0 tree and re-apply application-specific customizations. Highest confidence, highest effort, appropriate if the existing fork is lightly customized.
2. Selective cherry-pick — take the CI and dependency work (PRs #91–#101 minus #95) into the existing 4.13.4 fork and defer the user/admin restructure. Lowest risk if the current tree is heavily customized.
3. Full merge — only viable if the fork has minimal divergence from upstream and the team can absorb the namespace churn in one pass.

For new projects, start at 4.14.0 and skip the question entirely.

Compatibility. Confirm the host environment matches: PHP 8.4 is exercised in CI, but verify the actual composer.json floor, since CI-on-8.4 does not guarantee a raised minimum. Verify the Filament constraint is not pinned to exactly 4.14.0. Verify Node/pnpm versions against the workspace config.

Sequencing. (1) Pin the target commit or tag explicitly — never track main for a production scaffold. (2) Stand up 4.14.0 in a scratch environment and run the full test suite plus PHPStan before touching the real fork. (3) Diff the 4.13.4 → 4.14.0 tree to enumerate every relocated class from PR #95. (4) Migrate models/auth first, resources second, since login flows are the blast radius. (5) Re-run migrations from scratch on a clean database, then against a populated copy, to catch migration ordering issues. (6) Freeze the fork at a known-good tag and record the upstream commit it derives from.

Operational Impact

Maintenance. Expect ongoing manual work. A starter kit forks immediately, so Dependabot PRs merged upstream do nothing for you — the security patching of shell-quote and source-map-js in this release is illustrative: you inherit the fix only if you re-sync. Budget a recurring sync cadence (monthly or per-upstream-minor) and treat the fork as owned code, not a dependency.

Support. Community-only, single maintainer, no LTS, no stated deprecation policy. The release-notes quality is thin — PR titles only, no narrative on the user/admin restructure. Realistically, the team's own engineers are the support tier for anything beyond "does it boot."

Scaling. Application-level scaling is standard Laravel/Filament: queue workers, session/ cache drivers, and Filament's own performance characteristics under large resource counts. Nothing in this package constrains scale, but nothing helps either — it is a starting point, and Filament admin panels with hundreds of resources and unfiltered tables will need the usual attention (indexing, eager loading, table query scoping) that the scaffold does not provide.

Failure modes.

• Silent divergence: the fork drifts, upstream fixes are never merged, and a transitive dependency CVE goes unpatched for months. This is the dominant risk and it is organizational, not technical.
• Partial upgrade: merging 4.14.0 without completing the user/admin package migration leaves duplicate model classes or an auth guard pointing at a stale namespace — a hard failure at login, which is the worst place to find it.
• Transitive dependency breakage: the pnpm overrides pin patched versions of shell-quote and source-map-js; a future pnpm upgrade or a team member running npm install can silently bypass them.
• Upstream churn: at this release velocity, main is not a stable reference. Pinning is mandatory.
• Auth regression: PR #95 touches login. Any auth customization in the fork must be re-validated end-to-end — login, logout, password reset, remember-me, guard switching between user and admin.

Ramp-up. Engineers need Laravel, Filament v4, Livewire, Tailwind, and pnpm workspace familiarity before they are productive. For a team already on the Laravel/Filament stack, allow roughly a day to scaffold and orient, and longer to internalize the user/admin split. For a team new to Filament, budget a week — Filament's resource and form abstractions are the steepest part and the scaffold does not teach them. Document the fork's divergence from upstream from day one; the cost of reconstructing that history later compounds with every release like this one.