Kompass Laravel Package

Technical Evaluation

Architecture fit

• Kompass is a package-shaped Laravel CMS (Secondnetwork\Kompass\, auto-discovered KompassServiceProvider) rather than a standalone app. That is the right shape for an existing Laravel monolith: install via Composer, publish migrations and stubs/, and route content through Blade views namespaced kompass::.
• It is opinionated on the TALL stack: Laravel 11/12, Livewire 4, Tailwind 4, Alpine, plus Preline UI and DaisyUI on the admin surface. Fit is high only if your frontend is already Blade + Livewire; if your product surface is Inertia/Vue/React or a separate SPA, the admin and public rendering paths diverge and you pay an integration tax on both sides.
• The service provider carries real global state: morph maps for Page, Post, and Datafield are registered at boot. This is convenient but it is a package reaching into polymorphic resolution for the whole application — a collision risk if the host app or another package already defines relations on those morph aliases.
• Content modeling leans on pages, posts, and datafields with slug generation via Str::slug. That is a conventional, understandable model, but it is also a fixed one; anything beyond flat pages + posts (localization, multi-site, structured content types, versioning) needs to be assessed as a gap rather than assumed.

Integration feasibility

• Mechanically straightforward: composer install, php artisan migrate, publish stubs and assets, then bun install / npm run build into public/assets/build. The friction is that a headless CMS package requires a Node toolchain in your build and release pipeline — a real cost if backend deploys are currently PHP-only.
• Vite is configured to emit into public/assets/build. Confirm this does not collide with the host app's own Vite/asset manifest before committing; asset pipeline collisions are the most common cause of "works locally, broken in prod" with packages like this.
• Livewire 4 attributes (#[Locked], #[Layout]) are used proactively. If Livewire 4 is not yet stable in your dependency graph, that is a hard blocker, not a soft one — it pins your framework upgrade cadence to a package's prerelease choices.

Technical risk

• Adoption is thin (10 stars) and the repository states no dedicated test suite in tests/. For a CMS that owns content, routing, and slugs, the absence of a characterization suite is the single largest risk: you cannot distinguish an upstream regression from your own change during upgrades.
• Bus factor is effectively one. There is no stated support model, no security disclosure policy, no compatibility matrix, and no back-compat commitment. Rector config gives style/refactor consistency, not behavioral safety.
• The release date (2026-10-07) should be verified against the tag history — an anomalous date is a supply-chain hygiene question worth clearing before the package enters a production dependency graph.
• Cache invalidation is implemented in model boot hooks (create/update/delete). It is simple and correct for editorial traffic, but it implies write-coupled cache flushes and possible invalidation storms under bulk imports or programmatic content sync.
• License is MIT — permissive and forkable, which materially de-risks the bus-factor concern. The mitigation is budget, not legal.

Key questions

1. What is the supported Laravel/PHP/Livewire version matrix, and is Livewire 4 GA or a moving target?
2. Is there any test coverage (CI, static analysis, smoke), and what is the upgrade/back-compat policy across minor versions?
3. Is this a CMS package or a starter kit? Does it expect to own the public site, the admin, or both?
4. How are content types extended beyond page/post — custom fields only, or custom models?
5. Multi-language, multi-site, drafts/preview, and scheduled publishing: supported, planned, or out of scope?
6. Media library, roles/permissions, and audit trail — provided or left to the host app?
7. What is the vendor view-override story (kompass:: prefix) and does it survive composer update?
8. Content export path: can we get structured data out without a bespoke dump, and what is the lock-in surface?

Integration Approach

Stack fit

• Greenfield Laravel monolith on Blade + Livewire: strong fit. You inherit an admin, a content model, and a rendering path in one dependency.
• Existing Laravel app with a non-Livewire frontend: partial fit. Consider deploying Kompass as an isolated admin/content service behind the same app — but understand you are then maintaining two rendering paradigms.
• Non-Laravel or polyglot estate: reject. The value is inseparable from the framework conventions.

Migration path

• Greenfield: lowest cost. Publish stubs, model content types, theme kompass:: views, build assets in CI, ship.
• Brownfield from WordPress/Statamic/legacy: budget for a real migration project. Map legacy entities into pages / posts / datafields, migrate media, and generate a slug-to-slug redirect map — Str::slug normalization will silently change URLs and break SEO if you don't.
• Brownfield from another Laravel CMS: check morph alias collisions first; the service provider's morph map may conflict with existing polymorphic relations.

Compatibility

• Pin exactly: PHP version, Laravel minor, Livewire major, Node/Bun and Vite versions. Lock the Node toolchain in CI and in the deploy image.
• Validate Tailwind 4 + Preline + DaisyUI against your existing design system before theming; Tailwind 4's engine change is not a drop-in for a Tailwind 3 app.

Sequencing

1. Spike (1 sprint): install into a throwaway Laravel 11/12 app, run migrations, build assets, create/edit/publish a page, override one kompass:: view. Confirm Livewire 4 stability and asset output path.
2. Security & dependency review: pin versions, run composer audit, npm audit, verify release provenance, and record the fork/maintenance decision.
3. Characterization tests: before building on it, write smoke tests for create/update/delete → cache flush, slug generation, and route resolution. This is your regression net for upstream bumps.
4. Content model mapping: enumerate required types and fields; explicitly list gaps (i18n, versioning, scheduling) and decide build-vs-fork.
5. Theming & admin UX pass: override views, align with brand, review editorial workflows with actual content editors.
6. Content migration + redirect map, run in parallel with redirect validation.
7. Performance and failure-mode testing: bulk import, cache invalidation behavior, concurrent editing.
8. Cutover behind a feature flag with a documented rollback to the previous CMS.

Operational Impact

Maintenance

• You will effectively co-own this package. Plan for a named internal owner, a pinned version, a fork-or-patch policy in vendor/ avoidance (prefer upstream PRs or a maintained fork), and a documented procedure for applying upstream changes.
• Because there is no test suite, every composer update is an unverified change. The mitigation — your own smoke and characterization tests — must be built and owned from day one, not retrofitted.
• Watch for published-view drift: any kompass:: view you override can be quietly bypassed when upstream renames or restructures templates. Diff published views on every upgrade.

Support

• Community-only, single maintainer, no SLA, no stated security process. Treat incident response as internal. Budget engineering time proportional to how business-critical content publishing is.
• MIT licensing means you can fork and self-support; that is the escape hatch and should be documented as the contingency plan, with an estimate attached.

Scaling

• Editorial/admin scaling on Livewire is fine for tens of concurrent editors; it degrades on large table renders and heavy component payloads, so paginate and lazy-load any content listing.
• Delivery scaling depends entirely on the host app: Kompass renders through Laravel, so response caching / CDN / static generation is your responsibility. The model-boot cache flush is a full-invalidation pattern — under high write volume or batch imports, expect invalidation churn and consider debouncing or tag-based invalidation.
• Database growth from datafields and block relations should be indexed and monitored; no evidence of built-in query tuning for large content sets.

Failure modes

• Upgrade regression with no test net — silent breakage in publishing or routing.
• Morph alias collision — polymorphic relations across the app resolve incorrectly.
• Asset pipeline collision — Vite output into public/assets/build conflicts with host build; broken admin CSS in production only.
• Slug drift — content migration or slug regeneration produces 404s and SEO loss without a redirect map.
• Cache invalidation storms — bulk import or sync overwhelms the cache layer.
• Livewire major bump — package pins attributes to a version that later changes semantics.
• Abandonment — maintainer stops releasing; you must fork, and your fork now diverges from any future upstream.

Ramp-up

• A mid-level Laravel developer with Livewire experience is productive on content modeling and theming in roughly 1–2 weeks; without Livewire, add a week for the reactivity/payload model.
• Frontend contributors need Tailwind 4, Preline, and DaisyUI familiarity — this is a distinct stack from a Tailwind 3 + component-library setup and should be scheduled, not assumed.
• Editors need a short enablement pass on the admin, particularly drafts/preview and media handling, plus a documented "what to do when publishing fails" runbook given the lack of vendor support.
• Recommend a decision gate after the spike: proceed only if Livewire 4 is stable in your graph, asset build isolation is proven, and you have committed to owning tests and a fork contingency.