Wiki Bundle Laravel Package

Technical Evaluation

Architecture fit

• The package under review (nowo-tech/WikiBundle, v1.6.4) is a Symfony bundle, not a Laravel package: Twig views (manage/page_edit.html.twig), Symfony Form rendering (form_row, form_end, render_rest), and Symfony-ecosystem dependencies (nowo-tech/form-kit-bundle, nowo-tech/tiptap-editor-bundle, nowo-tech/phpstan-frankenphp).
• For a Laravel codebase this is a poor native fit: Laravel ships Blade, not Twig, and does not use the Symfony Form component or bundle/DI kernel conventions. Only the pure-PHP portions (HTML→Markdown conversion via league/html-to-markdown, content/domain services) are portable.
• Fit improves substantially if the host is Symfony, or if the wiki is deployed as a separate Symfony service behind an API rather than embedded in the Laravel app.

Integration feasibility

• Composer installation is straightforward; runtime feasibility is not. Embedding requires Twig, Symfony Form, and bundle registration inside Laravel — achievable only via community bridges and custom service-provider wiring, with no upstream support.
• Frontend is a second integration surface: the release touches pnpm/npm lock files and demos, and the Tiptap editor bundle is a JS asset dependency. This must be reconciled with a Laravel Vite pipeline.
• Net: technically possible, operationally discouraged for an in-process Laravel integration; viable as a sidecar service.

Technical risk

• Primary risk — behavioral template change shipped as a patch. v1.6.4 replaces render_rest: false with an explicit child loop ({% for child in form %} + not child.rendered + form_row(child)) and closes with form_end(form). Any host that overrides or subclasses this template, or that relied on the previous "render nothing else" contract, can now emit duplicate or unexpected fields on the page-edit screen. No tests are cited for this change — only a view edit and an UPGRADING anchor.
• Secondary risk — minor dependency bumps inside a patch release. tiptap-editor-bundle 1.3.10 → 1.5.0 and form-kit-bundle 2.7.1 → 2.12.0 are minor-version jumps landing in a patch, both in the form/editor path we would depend on. league/html-to-markdown and jsdom bumps are low risk.
• Governance signal is positive but inward-facing: the changelog references internal REQ-* rules, a dated dependency campaign, a "Spec Kit inventory (92/92)", and .php-cs-fixer parallel config. This indicates disciplined process, but the release delivers no user-facing features — value is maintenance only.
• Version/constraint opacity: PHP and Symfony version floors are not stated in the notes; these determine whether the package can even be evaluated in our runtime.

Key questions

1. Is the target host actually Laravel, or Symfony? If Laravel, is a sidecar/API deployment acceptable, or is in-process embedding a hard requirement?
2. What are the declared PHP and Symfony version constraints for 1.6.4, and are the phpstan-frankenphp / dev dependencies excluded from production installs?
3. Does UPGRADING.md#to-164 instruct hosts to manually update overridden templates? What is the project's BC policy for rendered markup — is template output considered public API?
4. Are there automated tests covering page_edit rendering, or is the child-loop change unverified?
5. Is tiptap-editor-bundle 1.5.0 compatible with a Vite-based asset build, and does it require a specific Node/pnpm toolchain?
6. What is the maintainer count and release cadence? Five Dependabot PRs in one patch implies high churn we would need to absorb.

Integration Approach

Stack fit

• PHP/Composer layer: compatible. Framework layer: incompatible with Laravel idioms (Blade vs Twig, no Symfony Form, no bundle kernel).
• Recommended posture: evaluate, do not adopt in-process. Two viable shapes — (a) standalone Symfony deployment exposing the wiki over HTTP/API to the Laravel app; (b) extract only the portable domain pieces (markdown conversion, content model) if wiki scope is narrow.
• If in-process embedding is mandated, budget for a maintained internal adapter (Twig bridge + service provider + template overrides) and treat it as owned code, not a dependency.

Migration path

• No prior assessment exists (data set was empty), so there is no incumbent version to migrate from — this is a greenfield adoption decision, not an upgrade.
• First step is a time-boxed spike on the exact stack, pinned to 1.6.4, before any commitment.
• If a spike succeeds, vendor/fork manage/page_edit.html.twig so we control the render contract rather than inheriting future silent changes.

Compatibility

• All v1.6.4 dependency moves are within-major (5.1.3→5.1.4, 1.2.3→1.3.0, 1.3.10→1.5.0, 2.7.1→2.12.0, 30.1.2→30.1.3). Low direct risk; the two minor bumps in the form/editor path warrant explicit regression coverage.
• The template change is the only compatibility concern: it is source-compatible but output-incompatible for anyone overriding the view. Our own overrides must be re-validated against the child-loop contract.

Sequencing

1. Confirm framework target and record PHP/Symfony constraint floors.
2. Pin 1.6.4; run a 3–5 day spike in an isolated branch (or sidecar container).
3. Prove the asset pipeline: Tiptap editor build under Vite/pnpm, independent of the bundle's demo tooling.
4. Audit for any existing page_edit template overrides and re-test rendering against the new child-loop behavior.
5. Visual + DOM regression on the wiki edit page (field count, hidden fields, CSRF token placement from form_end).
6. Decision gate: adopt (sidecar) / extract (partial) / defer. Record the decision with the template-BC caveat.

Operational Impact

Maintenance

• Steady, dependabot-driven churn (five dependency PRs in a single patch) means frequent low-value releases to track. Pin exact versions and batch upgrades on a monthly cadence rather than per-release.
• Template-level changes shipped as patches raise ongoing maintenance cost for anyone overriding views: every release requires a rendering diff review.
• Positive: internal REQ compliance, doc TOCs, canonical bug template, and refreshed Spec Kit inventory indicate process hygiene and predictable release notes.

Support

• Community OSS; no vendor SLA, no stated LTS. UPGRADING.md, a canonical bug-report template, and FrankenPHP troubleshooting docs are good self-service signals but do not constitute support.
• Internal REQ-* identifiers are not resolvable externally — expect limited ability to trace intent behind changes.

Scaling

• Application-level PHP; no infrastructure or performance claims in the release. Wiki read traffic scales conventionally.
• Save-path is the hot spot: HTML→Markdown conversion is CPU-bound per edit — acceptable at moderate content volume, worth load-testing only if bulk imports are planned.
• CI cost increases modestly: the bundle carries its own Composer and pnpm/npm lock files plus demo builds; if we vendor it, those must be trimmed from our pipeline.

Failure modes

1. Silent field duplication on page edit — host template overrides combined with the new child loop and form_end re-render remaining children; users see duplicated inputs or mis-placed CSRF/hidden fields. Highest-likelihood failure of this release.
2. Transitive breakage from minor bumps in tiptap-editor-bundle 1.5.0 or form-kit-bundle 2.12.0 inside a patch, surfacing as editor initialization or form-theme errors.
3. Asset pipeline divergence — bundle assumes pnpm/npm lockfile flow; our Vite build may not resolve the editor bundle, yielding a non-functional editor with no server-side error.
4. Framework impedance failure — Twig/Form/Kernel boot errors if in-process Laravel embedding is attempted without a maintained adapter.
5. Undetected regression from unverified view change — no tests cited for the template edit, so defects would be found by end users rather than CI.

Ramp-up

• A Laravel-fluent PHP developer needs roughly 1–2 weeks to become productive in Twig + Symfony Form theming and the bundle's override conventions; the form-rendering semantics (render_rest, form_end, child.rendered) are the specific learning curve.
• Add ~1 week of frontend ramp for the Tiptap/asset side if the editor is in scope.
• Adopting the sidecar-service shape reduces ramp-up for the Laravel team (API contract only) at the cost of a second deployable and its own operational runbook.