Text Widget Laravel Package

Product Decisions This Supports

• CMS build-vs-buy: Informs whether to adopt Victoire's widget ecosystem (Symfony-based text block) or standardize on a modern page-builder (Filament, Nova, Statamic, headless CMS). The 2.43 opportunity score suggests the need for a text block is real even if this implementation isn't.
• First-party rich-text block scope: Use as prior art for the block contract — fields, rendering, i18n hooks — when scoping an in-house text widget, not as a dependency.
• Roadmap de-risking: 2017 last release, 3 stars, 0 dependents flags any roadmap item that assumes this as a foundation. Cost to fork and re-maintain likely exceeds a clean rebuild.
• Stack commitment: Package is Symfony/Victoire, not Laravel. Surfacing this forces the real decision — which PHP ecosystem the team commits to (Laravel vs Symfony) — with hiring, tooling, and vendor-lock implications.
• Legacy migration scoping: If already on Victoire, each bundle (e.g., this text widget) becomes one replaceable migration unit, enabling per-iteration cutover.

When to Consider This Package

Consider it when:

• You run an existing Symfony/Victoire install and must preserve a text block during incremental migration.
• You need prior art for a widget/block interface (schema, rendering, i18n) before designing your own.
• Licensing/compliance requires inventorying every text-rendering component in the stack.

Look elsewhere when:

• You're on Laravel — the Symfony coupling won't install cleanly and drags DI/ORM baggage in. Use Filament, Nova, or a headless CMS instead.
• You need maintained dependencies — no release since 2017, no security patch path.
• You need modern editor UX (collaborative editing, sanitization, WCAG conformance) — rebuild behind a stable interface.
• You need vendor SLA — there is none.

How to Pitch It (Stakeholders)

Executives (1 paragraph): This is a narrowly scoped, unmaintained text-widget component from a Symfony CMS. It is not a Laravel package and carries near-zero adoption (3 stars, 0 dependents) with no releases since 2017. Recommendation: do not adopt; treat as a design reference only. Adding it would create a single-maintainer liability with no security or upgrade path — a worse outcome than building a simple rich-text block in-house behind a stable interface. The signal is that a text block is table-stakes for any CMS; the specific implementation is not.

Engineering: Use this as a spec, not a dependency. Extract the block contract (fields, rendering, i18n hooks) and implement a first-party text block that fits our stack — Laravel: Filament field + Blade component; Symfony: rebuild on Symfony 6/7. Effort: days for a basic block, weeks if collaborative editing is required. Do not pull in Victoire — it forces Symfony coupling and an unmaintained transitive tree. If already on Victoire, isolate this as one migration unit and replace per iteration.