Fluid Schema Generator Laravel Package

Product Decisions This Supports

• Editor/tooling investment for template authors. The package emits XSD schemas describing Fluid ViewHelper arguments, which powers IDE autocomplete and validation. That's a developer-experience decision, not a runtime capability—it belongs in a DX/tooling budget line, not the product roadmap.
• API surface for custom ViewHelpers. If we publish ViewHelpers for other teams or extension authors, generated schemas become a machine-readable contract. That informs whether we treat ViewHelpers as a public API with a compatibility promise.
• Build vs. buy vs. borrow. The honest read: borrow the approach, not the dependency. Archived, 17 stars, zero dependents means adopting it is equivalent to forking it—so the decision is "do we want to own a small build step?" rather than "do we adopt a package?"
• Scope correction. This is a TYPO3/Fluid ecosystem tool, not a Laravel package. If the request came in framed as "a Laravel/PHP package," the first product decision is to close it out unless we actually run TYPO3 or standalone Fluid.
• Use cases it would serve: CI validation of templates, onboarding developers to a large custom ViewHelper library, static analysis of template arguments.

When to Consider This Package

Consider it when all of the following hold:

• We are on TYPO3 (or standalone Fluid) and ship custom ViewHelpers inside our own packages.
• Template authors are a meaningful population and IDE autocomplete/validation has measurable value.
• We are willing to vendor or fork—because archived status means "we are the maintainers now."
• The work is a small, isolated build step generating .xsd artifacts; value is DX-only, failure mode is cosmetic.

Look elsewhere when:

• The stack is Laravel/Blade, Twig, or anything non-Fluid. Applicability is zero; don't spend a spike on it.
• We are on modern TYPO3 (v12/v13). Verify whether core tooling or maintained community packages now cover ViewHelper schema generation before resurrecting an archived project.
• We need supported tooling with an upgrade path or SLA. Archived + zero dependents is a strong negative signal on ecosystem health.
• The underlying need is simply "catch bad templates in CI." A Fluid linter or PHPStan-style static analysis may solve it more directly than generating XSDs.

How to Pitch It (Stakeholders)

Executives: This is a small, MIT-licensed developer-experience utility from the TYPO3 ecosystem. It generates editor schemas so developers get autocomplete and validation when writing Fluid templates. It is archived and effectively unmaintained—17 stars, no downstream dependents—so it should be treated as a reference implementation or fork candidate, not a dependency we adopt. Recommendation: no investment. Revisit only if we run TYPO3 with a large custom ViewHelper surface, in which case budget a short spike and plan to own the fork. Note also that the original request framed this as a Laravel package; it isn't, which is itself a reason to deprioritize.

Engineering: The tool derives XSDs from ViewHelper argument definitions, enabling IDE completion and template validation. The value is real but narrow and purely DX. Because the project is archived, adoption implies forking and owning it—roughly a day or two of setup plus ongoing drift risk as framework versions move. If our stack is TYPO3/Fluid, run a timeboxed spike and vendor the output; otherwise close this out and, if the goal is template safety, evaluate a linter or static analysis instead.