Fluid Documentation Generator Laravel Package

Product Decisions This Supports

• The framing to settle first: this is a PHP package, not a Laravel package. It has no service provider, no config publishing, no Blade or Artisan conventions, and it documents TYPO3 Fluid ViewHelpers specifically. If the question on the table is "what do we adopt for our Laravel product's documentation?", the answer is decide to exclude it — and record that decision so it isn't re-litigated. The decision it does support is scoped to the TYPO3/Fluid surface area of the org, if one exists.
• Build vs. buy for reference documentation. The real choice is hand-maintain a ViewHelper reference (a recurring senior-engineer tax that decays with every merge) versus derive it from source at build time. This package is the "derive" option: one --dev dependency and one CLI invocation in CI. The PM decision is which side of that trade we want to fund.
• Developer-experience roadmap with a measurable KPI. Auto-generated reference docs are an onboarding lever. If our product surface includes custom ViewHelpers, every "which parameters does this tag take?" question routed to a senior engineer is a cost. Tie adoption to a metric — time-to-first-PR for new hires, or the volume of usage questions in support — rather than to a docs-quality vibe.
• Standardization across a package portfolio. The CLI accepts one-to-many JSON configs and their order determines the index page order, so a single pipeline can produce a consistent reference across N extensions instead of N bespoke doc sites. That is an org-level consistency decision, not a tooling detail.
• Whether documentation freshness becomes a release gate. Because output dir is configurable via FLUID_DOCUMENTATION_OUTPUT_DIR and generation is a single command, this is trivially schedulable. The decision: does the docs build run nightly (best effort, rot is possible) or block the release tag (docs must regenerate cleanly, rot is impossible)? The second is cheaper to defend and more expensive to wire.
• Toolchain consolidation. If Sphinx or render-guides is already in the pipeline, this slots in rather than adding a static-site stack. The PM value there is fewer tools we own, which usually outweighs the feature list.
• Explicit scoping of the docs product. Output is RST plus a JSON metadata file consumed by a render-guides directive. That defines what the docs site can be: a structured technical reference — not a tutorial site, marketing site, or interactive playground. Write that boundary down so stakeholders don't assume more.

When to Consider This Package

Worth evaluating when:

• The relevant code is TYPO3/Fluid and the thing to document is a set of ViewHelper classes — a custom extension, an internal ViewHelper library, or a Fluid Standalone project. It scans ViewHelper classes; it has nothing to say about arbitrary PHP classes, and nothing at all about Laravel controllers, models, or Blade components.
• Documentation is destined for RST — Sphinx or TYPO3's render-guides. If that pipeline exists, integration cost is close to zero; if it doesn't, you are standing up a rendering stack to consume the output.
• The audience is technical: integrators and developers who want parameter signatures, types, and per-ViewHelper pages, not narrative guides.
• You have enough ViewHelpers that manual upkeep hurts — dozens or more, or several packages. Below that, config files and CI wiring cost more than they save.
• You can install it as a --dev dependency inside the Composer project that contains the ViewHelpers. This is a hard structural constraint, not a preference. A repo that only consumes ViewHelpers from vendor/ is a poor fit.
• LGPL-3.0 is acceptable for a build-time dev tool. Usually fine, but route it through legal if your policy scrutinizes copyleft anywhere in the dependency graph.

Look elsewhere when:

• The stack is Laravel/Blade, Symfony/Twig, or plain PHP templating — i.e. the common case for a "Laravel/PHP package" evaluation. One star and zero dependents are a signal there is no general-purpose fallback value here; don't adopt it hoping to repurpose it.
• You need Markdown or HTML output for GitHub Pages, Docusaurus, or an internal portal. Output is RST-first; conversion is work you own.
• You need API reference (OpenAPI-style) or interactive docs. This is static, build-time generation.
• The org has no TYPO3/RST expertise. The failure mode is a generated directory nobody knows how to publish.
• You need localization. Output is single-language.
• Adoption risk tolerance is low. One star, zero dependents, and a changelog dominated by a small number of contributors mean you are an early adopter — budget time to read the source when something breaks. Active releases (4.4.x, most recently 2026-04-03) under the TYPO3 Documentation org offsets some but not all of that risk.

Price in a fallback: phpDocumentor for non-Fluid classes, or a hand-rolled Markdown generator if the RST constraint ever disappears.

How to Pitch It (Stakeholders)

For executives

Our Fluid ViewHelper reference is maintained by hand, so it drifts and consumes senior engineering time on work that doesn't differentiate the product. This package generates that reference from the source code at build time — one dev dependency and one command in CI. What it buys: documentation that can't silently go stale, faster onboarding for developers joining our TYPO3 work, and fewer support questions about correct ViewHelper usage. It plugs into the documentation pipeline we already run, so there's no new platform to operate or license.

Two caveats worth stating up front. First, this is not a Laravel tool — it applies only to the TYPO3/Fluid part of our estate, and if that surface area is small or shrinking, we should decline it and close the question. Second, it is a narrow tool with a very small public user base, so we'd be an early adopter. I'd treat it as a bounded experiment with a named success metric — e.g. zero manual edits to the ViewHelper reference for two release cycles — and a clear exit if it doesn't hold.

For engineering

One --dev Composer dependency, installed inside the project that owns the ViewHelpers. JSON config per package — name, namespace alias, target namespace — validated against a shipped schema. One CLI invocation per config, wildcards and ordering supported, output directed via FLUID_DOCUMENTATION_OUTPUT_DIR. Result is an RST tree plus a JSON metadata file that render-guides turns into the published reference.

What we own: the config files (small, version-controlled), the CI job, and the rendering stack. What we don't own: keeping the parameter tables in sync with the code — that comes from the ViewHelpers themselves. The realistic risks are RST/render-guides unfamiliarity and the low-traffic upstream; pin the version and read the source before upgrading across a major.