Charaza Ui Laravel Package

Technical Evaluation

Architecture fit

The package is described two incompatible ways, and that ambiguity is the first thing a TPM has to resolve because it flips the entire risk profile:

• Repo metadata says "Laravel 7 Scaffold of Savannabit's Admin CRUD generator" — that reads as "type": "project", meaning you clone/fork the application and own every line.
• The package description says "Blade component library … publishable config and views" — that reads as a Composer dependency you install and compose against.
• v3.1.0 release notes describe a full app scaffold (Jetstream, Livewire, profile flows, Docker, app-exec wrapper) plus a re-brand.

Until composer.json "type" is confirmed, treat this as a blocking discovery item, not a doc nit. "Library we depend on" and "codebase we own" are different budgets, different support models, and different exit costs.

Where the fit is genuinely clean: internal admin/back-office surfaces — list/detail/edit over a handful of models, auth, and profile screens. That is a recurring 2–4 week plumbing tax on every internal tool, and the generator's output is the whole value case. Fit is poor-to-none for customer-facing surfaces, API layers, or anything in an audit scope.

Integration feasibility

Feasible only as greenfield Laravel 7/8 — and only via clone/fork, not composer require. On Laravel 10/11 the constraint either fails resolution (the cheap, good outcome) or resolves into an unpatched framework (the expensive outcome). Do not attempt to bolt this onto an existing modern app; if all you want is the Tailwind Blade components, copy the .blade.php files into your repo and drop the dependency entirely.

Technical risk

• EOL framework. v3.1.0 targets Laravel 8 (the repo title still says 7); both are past security support. Adopting pins the product to an EOL stack and an unmaintained upstream. Framework CVE patching becomes your team's job.
• No maintenance signal. Last release 2020-11-20, 50 stars, 0 dependents, no semver contract. ^3.1.0 is meaningless — pin an exact commit or vendor the code so an upstream deletion can't break your build.
• Re-brand residue. "Re-branded to charaza" with mismatched savannabits/charaza strings across config keys, view namespaces, asset paths, and mail views surfaces as unrelated-looking "view not found" / "class not found" errors. Budget a grep-and-fix pass on day one.
• Deployment standard drift. nginx → Apache2 inside the app container changes image build, ports, healthchecks, log paths, and reverse-proxy assumptions. If the org has an ingress standard, this needs a signed exception.
• Licensing/attribution gap. The rename shipped with no visible license note. Confirm a license file exists before forking, committing, and redistributing internally.
• Supply-chain claim, not evidence. "Updated dependencies to their latest" is changelog prose; gate on a composer.lock diff and composer audit.

Key questions (answer before any sprint commitment)

1. Is composer.json "type": "project" or "library"? (cat composer.json)
2. Does a LICENSE file exist, and does it permit internal vendoring/redistribution?
3. Who owns the fork, and what is the written target date to escape Laravel 8?
4. Does the org's deployment/ingress standard permit Apache-in-app-container, or does this require an exception?
5. Does composer audit pass today, and what is the unpatched-CVE backlog we're accepting?
6. Is the intended surface strictly internal admin, with no customer or audit scope?

Integration Approach

Stack fit

Assume this stack: Laravel 7/8, Jetstream + Livewire 2 (pinned era), Tailwind, Blade components, Docker Compose with the app-exec wrapper, Apache2 in-container. It fits a greenfield internal admin monolith. It does not fit Laravel 10/11, Livewire 3, or an org with a proxy/ingress standard — those are hard incompatibilities, not configuration choices.

Migration path

Choose by identity, decided once:

• If library: php artisan vendor:publish --tag=charaza-views, then own overrides exclusively under resources/views/vendor/charaza-ui/.... Upgrades become a re-publish, not a diff. Keep docs/ui-overrides.md listing every touched vendor view.
• If scaffold: clone/fork, pin the exact commit, build on top. No composer require.
• If you only want the components and are on a modern framework: copy the Blade files in and own them. Drop the dependency.

Compatibility

• Tailwind content scanning must include vendor views or classes render unstyled in production while working in npm run dev.
• Livewire 2-era conventions are load-bearing. Dropping Livewire 3 in breaks component syntax and asset injection — budget that as a migration, not a version bump.
• Component name collisions with Jetstream (button, input, etc.) require namespacing or renaming.
• View caching will mask vendor overrides; view:clear + optimize:clear before debugging anything.
• $fillable omissions fail silently — a field added to migration + Blade but not $fillable or the Livewire $state/rules simply disappears.

Sequencing

1. Identity + license + audit gate (half a day, before anything else). Resolve type, license file, composer.lock diff, composer audit.
2. Fork and pin the commit. Record the pinned SHA in the repo README.
3. First boot: .env, ./app-exec up -d, key:generate, migrate --seed, storage:link. Find the mapped port in docker-compose.yml, not from memory.
4. Throwaway CRUD end-to-end (Post). Read every generated controller, FormRequest, and Blade view — the generator's conventions are the actual contract and are undocumented.
5. Establish wrapper components (field, button) in your own resources/views/components layer, forwarding $attributes. This is the cheapest insurance: call sites stay valid if you later rip the package out.
6. Layout-first standardization. Route every new screen through one layout; the moment a sidebar is copied into a second page, convert it to a component.
7. Only then generate against real domain models — migrations/model/factory handwritten first, generator as first draft, immediate review pass for authorization, FormRequest extraction, fillable/casts, pagination.
8. Tailwind config updated for vendor view scanning; docs/ui-overrides.md created.

Operational Impact

Maintenance

You are the maintainer of every adopted line. With no release since 2020-11-20 and no semver contract, "free scaffolding" is paid for in ongoing ownership. Extension points, in order of safety: publish config → publish/override views → wrap components in your own app layer → edit vendor code only by forking (merging upstream is unrealistic). Budget a forced framework upgrade inside the first year as a roadmap line item, not a footnote, and record a written EOL acceptance with a target date.

Support

Effectively zero external support: 50 stars, 0 dependents, single-vendor origin, no issue-triage signal. All support is internal. The generator's behavior is undocumented outside the code, so knowledge concentrates in whoever runs it first — capture conventions in a short internal doc or the second developer pays the discovery cost again.

Scaling

Traffic scaling isn't the constraint for an internal admin panel; team scaling is. Every new developer inherits the EOL tax, the undocumented generator conventions, and the pinned-version constraints. Contain the blast radius: scope this to internal admin screens only, keep it out of customer-facing and audit-scoped systems, and isolate it behind your wrapper component layer so it can be replaced without rewriting call sites.

Failure modes (and their signatures)

• Re-brand residue → "view not found" / "class not found" across config keys, namespaces, asset paths.
• Removed DB init data → seeders/tests that assumed prior rows fail or produce empty states; make seeders explicit and idempotent, assert counts in tests.
• Apache-in-container → 404s on pretty URLs (mod_rewrite/AllowOverride), 500s on storage writes (permissions), missing logs at the old nginx paths.
• Cached views → published overrides don't appear.
• Tailwind scan gaps → unstyled components in production only.
• Livewire 3 drift → broken component syntax and asset injection.
• composer audit backlog → CVEs you cannot patch without a framework upgrade.
• Silent $fillable gaps → submitted fields vanish without error.

Ramp-up

Budget discovery (identity, license, audit) as a gate before any roadmap commitment. Then one to two days for first boot and a throwaway CRUD, read file-by-file. Then a day to stand up wrapper components and a single layout. Realistic time-to-first-real-screen for a Laravel-fluent developer: 3–5 days; for a team unfamiliar with Livewire 2, double it, because the pinned versions cannot be treated as current docs. The value proposition pays back only if you're shipping multiple internal CRUD surfaces — a single one-off admin screen does not justify the EOL ownership.