Mathml Bundle Laravel Package

Product Decisions This Supports

• Server-side math rendering strategy (feature decision). Still only relevant after we've decided server-side rendering is desirable — no-JS delivery, email/PDF output, progressive enhancement, or SEO-indexable technical content. Version 4.0.0 doesn't change that calculus; it changes who can run it.
• Build vs. buy for a thin integration layer. The bundle remains a Symfony service-container wrapper around PHPMathML. 4.0.0 is a pure compatibility release — Symfony 7 support on PHP 8.2, with Symfony 2/3/4 dropped — not new math capability. That reinforces the existing read: the wrapper is cheap to replicate, and the real asset is the underlying library.
• Platform currency and upgrade coupling (new). 4.0.0 is a breaking major bump: adopting it pins us to PHP ≥ 8.2 and Symfony 5/6/7. That's a platform-floor decision, not just a library pick, and it should be recorded alongside our PHP/Symfony upgrade roadmap rather than treated as an isolated dependency.
• Roadmap input for math-heavy surfaces. Unchanged — LMS/quiz engines, formula authoring, scientific/engineering docs, textbook-style content, accessibility mandates. If none are on the roadmap, this package has no product role.
• Accessibility and standards compliance bets. MathML over rasterized images or raw LaTeX is still the accessibility/portability position this supports; 4.0.0 neither strengthens nor weakens it.
• Vendor/technical-debt triage. 4.0.0 is evidence of ongoing maintenance (a real 3.0.2 → 4.0.0 tag history, contemporary Symfony support), which meaningfully retires the earlier "release metadata can't be verified" concern. It does not retire the bus-factor concern: still a single maintainer, still no visible dependent ecosystem. Adopting remains a decision to own a fork — now with the added obligation to track Symfony major bumps on the maintainer's schedule, not ours.

Net PM read (revised): the package is better maintained than assumed but no more strategic. Still prototype-grade, not a platform bet. The 4.0.0 breaking change slightly raises the cost of adopting without a pin — so if we spike, pin ^4.0 deliberately and budget for the next Symfony major.

When to Consider This Package

Consider it when:

• The product is a Symfony 5/6/7 application on PHP ≥ 8.2 and the team wants a DI-registered service rather than a bespoke integration. On older Symfony or PHP < 8.2, 4.0.0 is simply unavailable — use 3.0.2 or stay out.
• Output targets are non-JS or JS-hostile: transactional email, PDF generation, RSS/Atom, static site generation, or server-rendered pages where shipping KaTeX/MathJax bundles is undesirable.
• We need MathML specifically — accessibility mandates, downstream consumers that expect MathML, browser-native rendering as the delivery mechanism.
• We are running a time-boxed spike and want the fastest path to a working prototype, with the explicit understanding we may replace the wrapper in-house.
• Formula complexity is moderate (fractions, superscripts, roots, matrices) rather than full LaTeX fidelity with macros and packages.

Look elsewhere when:

• Non-Symfony stack — Laravel, plain PHP, or a non-PHP service. 4.0.0 sharpens this: the package's only value is Symfony wiring, and it now tracks Symfony majors exclusively. In Laravel, bind the underlying PHPMathML library directly.
• We're pinned below PHP 8.2 or Symfony 5. 4.0.0 hard-drops Symfony 2/3/4; there is no compatibility shim, and the maintainer has signalled the support window is "current majors only."
• LaTeX is the authoring format and fidelity matters — KaTeX/MathJax remain far more mature and better understood by authors.
• Maintenance and security posture are gating requirements. Improved, but 4.0.0 is still a one-person release with no ecosystem pressure-testing, no CVE response path, and real bus-factor risk on a customer-facing, long-lived surface.
• You need a supported vendor relationship — still none.
• Client-side rendering is acceptable — usually it is, and it removes this dependency entirely.
• We can't absorb a breaking major. 4.0.0 demonstrates the maintainer will bump majors for framework compatibility. Anyone depending on this must have a plan for the next Symfony release.

How to Pitch It (Stakeholders)

To executives (one paragraph): This is a small Symfony integration package that lets our PHP backend emit MathML — the web standard for mathematical markup — instead of relying on JavaScript in the browser to draw formulas. The strategic value isn't the package; it's the capability: server-rendered math works in emails, PDFs, and no-JS contexts, and MathML is the accessible, standards-based format. The new 4.0.0 release is a maintenance signal, not a feature release: it adds Symfony 7 support and requires PHP 8.2, while dropping older Symfony versions. That's genuinely reassuring on upkeep — it's a live project tracking current frameworks — but it also confirms the package follows the maintainer's upgrade schedule, so adopting it means upgrading when they do. The integration surface remains tiny, so a short, time-boxed spike is cheap and lock-in is limited; we'd pin the version and likely absorb the wrapper into our codebase if we commit.

To engineering (the ask): Don't evaluate this as "should we depend on this bundle" — evaluate it as "is server-side MathML generation worth having." 4.0.0 changes only the compatibility envelope: Symfony 7 added, PHP 8.2 required, Symfony 2/3/4 removed. Concretely: (1) confirm our app is on Symfony 5+ and PHP 8.2+ before considering it at all, otherwise stop; (2) in a ≤ 2-day spike, verify the underlying PHPMathML library handles our realistic formula set and renders acceptably in target browsers and assistive tech; (3) confirm the wrapper is still thin enough to vendor, and note that we'll inherit responsibility for the next Symfony major bump. Come back with bundle vs. in-house wrapper vs. KaTeX client-side, including maintenance burden of each. Default bias remains: prefer client-side unless a concrete delivery constraint (email, PDF, no-JS, accessibility mandate) rules it out.