Node Bundle Laravel Package

Technical Evaluation

Headline finding — framework mismatch. Despite being a Composer/PHP package, kunstmaan/node-bundle is a Symfony bundle, not a Laravel package. It ships symfony-bundle package type, a DependencyInjection/*Extension + compiler passes, Doctrine ORM entity mappings (annotations/XML), Twig templates, a Symfony SlugRouter/route loader, and — in its native distribution — an admin UI built on Sonata Admin, FOSUserBundle and Symfony ACL. None of that surface is consumable by Laravel's container, Eloquent, Blade or router. The package name on the ticket is misleading; treat this as "PHP, but not Laravel."

Architecture fit

• Domain model is genuinely good and reusable as a specification: Node → NodeTranslation (per-locale slug, title, online flag, hiddenFromNav, sequence) → Page/PagePart composition, plus draft/published versioning and per-node ACL. That is a well-shaped page-tree abstraction.
• Runtime fit with a Laravel application: effectively zero. There is no adapter layer, and writing one means reimplementing the bundle rather than integrating it.
• Fit with a legacy Symfony 2.x estate: plausible — but only as part of the full Kunstmaan Bundles CMS, not as a standalone drop-in.

Integration feasibility

• A Composer require will attempt to resolve Symfony 2-era constraints (symfony/symfony ~2.3, Doctrine 2.4-era, PHP 5.x). In any PHP 8 / Laravel 10+ project this is an unresolvable dependency graph, and forcing it with --ignore-platform-reqs will produce fatal errors on removed language features.
• Cost to "make it work" in Laravel ≈ cost to build a page-tree CMS from scratch, with the added burden of maintaining a foreign codebase. There is no partial-integration path.

Technical risk (high)

• Abandonment: last tagged release 2014-08-05; upstream Symfony 2.8 went EOL in Nov 2018. No security backports, no CVE response, no PHP 8 compatibility work.
• Adoption signal: 23 stars, 0 dependents is essentially no external validation and no third-party bug-finding. Caveat for the record: this repo is a subtree split of the KunstmaanBundlesCMS monorepo, so stars/release dates understate real activity — but even the parent project's split packages are Symfony-only and legacy-bound. Verify against Packagist and the monorepo before quoting these numbers upward.
• Transitive weight: the bundle assumes Sonata Admin, FOSUserBundle, Symfony ACL and Doctrine. Reusing 20% of it drags in 100% of a dead stack.
• Licence is the only clean item: MIT permits forking and commercial reuse; that is a fork-and-own decision, not a dependency decision.

Key questions for the business

1. Is the target application Laravel, or is there an existing Symfony 2 estate we are actually trying to extend? The answer changes the recommendation completely.
2. What is the requirement behind "we need pages" — a marketer-editable page tree, or a headless content API? Only the former maps to this bundle's value.
3. Is content localisation, per-node permissions and draft/publish in scope on day one?
4. Who owns a fork? If no named owner with Symfony experience exists, the fork is dead on arrival.
5. Buy vs. build vs. fork: what is the loaded cost of 6–10 engineer-weeks versus a licensed CMS or a Filament-based build?

Integration Approach

Stack fit

• Laravel + PostgreSQL/MySQL + a modern PHP runtime: no direct fit. Do not attempt to mount this bundle.
• Symfony 2.x monolith already running Kunstmaan Bundles CMS: fit is native — but adopt the full CMS distribution, not this bundle in isolation, and only as a maintained-fork decision.
• Anything greenfield: the correct move is to harvest the model, not the code.

Recommended path (Laravel target) — reimplement the domain, borrow the schema

1. Concept port, not code port. Re-create nodes, node_translations, node_versions, page_parts tables modelled on the bundle's schema. Use kalnoy/nestedset (or a closure table) for the tree, keeping parent/sequence semantics.
2. Routing. Replace SlugRouter with a single catch-all Laravel route plus a slug resolver: locale → node_translations.slug lookup → cached resolver map → controller dispatch to a page-type handler. Preserve the bundle's per-locale slug uniqueness and online gating.
3. Admin. Replace Sonata Admin with Filament (or Nova): tree resource, page-part repeaters keyed by a page_parts polymorphic table, draft/publish state machine, per-node policy for ACL.
4. Presentation. Blade components map 1:1 to the PagePart types; keep the "page = ordered list of typed parts" contract so marketing can compose pages without deploys.

Migration path (if content exists in a legacy Kunstmaan instance)

• Read-only extract from node / node_translation / page-part tables into the new schema via a queued, idempotent importer; hash slugs and assert 301 coverage before cutover. Treat URL preservation as a hard acceptance criterion.

Compatibility

• Pin nothing to this package. If a fork is mandated, pin PHP ≤ 7.x and Symfony ≤ 2.8 and accept the isolation cost; do not let it touch the Laravel runtime.
• Licence attribution: retain the MIT notice in any derived schema or code.

Sequencing

1. Week 0–1: feasibility spike to disprove reuse (expect to succeed at disproving). Deliver a one-page decision memo.
2. Week 1–2: schema and model port; tree operations and slug resolution with cache invalidation.
3. Week 3–4: admin UI (tree, drafts, page parts, ACL).
4. Week 4–5: localisation, SEO fields, redirects, sitemap.
5. Week 5–6: content migration, 301 audit, load test, cutover rehearsal.

Operational Impact

Maintenance

• Consuming the bundle as-is means owning an unmaintained Symfony 2 dependency with no upstream. Every PHP or framework upgrade becomes a fork-maintenance project.
• A concept port leaves the team owning ~6–8 weeks of bespoke code, but in a stack they can actually debug. That is strictly cheaper to operate over a 3-year horizon.

Support

• No vendor, no maintainers, no issue triage, no security advisories. Effective bus factor: zero. Any incident is internally resourced.
• Ramp-up cost is high and non-transferable: new hires need Symfony 2, Sonata Admin, Doctrine annotations and Kunstmaan-specific conventions — skills not present in a Laravel team and not useful elsewhere.

Scaling

• The underlying model scales acceptably: tree reads are DB-backed and cacheable; publish events invalidate a slug map; page rendering is read-heavy and CDN-friendly. Nothing here is a scaling blocker — the blocker is code health, not architecture.
• Watch the two known hotspots: N+1 hydration when rendering a nav tree (mitigate with eager-loaded tree + cached nav fragments) and page-part fan-out per request.

Failure modes to design against

• Stale slug cache after publish/unpublish → user-visible 404s or draft leakage. Mitigate with event-driven invalidation and a online/published_at predicate enforced at query level, never in the view.
• Draft content leaking to anonymous users — the bundle's online flag is the only gate; replicate it as a policy, not a controller check.
• Slug collisions and locale fallback ambiguity — enforce unique (locale, slug) at the DB level.
• ACL gaps if the admin layer is ported without the bundle's per-node permission model — decide explicitly whether per-node ACL is in scope or whether role-based admin access is sufficient.
• Migration URL breakage — 301 coverage is the highest-severity cutover risk; gate go-live on a crawl diff.

Recommendation for the steering group: reject kunstmaan/node-bundle as a dependency for a Laravel application; approve a short spike to mine its schema and page-part composition model, then build on Filament + nested-set, or buy a maintained CMS. If the estate is genuinely Symfony 2, escalate a separate fork-ownership and upgrade decision — this bundle is not a safe thing to adopt quietly in 2024.