Mathml Bundle Laravel Package

Technical Evaluation

Architecture fit — poor, and 4.0.0 reaffirms it. The 4.0.0 release moves mercurysolutions/mathml-bundle to Symfony 7's DI generation and drops Symfony 2/3/4. Nothing in the changelog introduces framework-agnostic packaging: no PSR-11 container bootstrapping, no Laravel service provider, no decoupling of the Bundle subclass from the DependencyInjection/Configuration tree or YAML/XML service definitions. If anything, the release tightens alignment with the exact Symfony layer we would have to discard. The reusable asset remains the underlying PHPMathML library; the bundle glue still has zero value in a Laravel context.

Integration feasibility — conditional, marginally improved on dependency resolution only. Laravel 11 and 12 ship Symfony 7.x components, so a symfony/* ^7 constraint is now materially less likely to collide than the Symfony 4/5-era constraints the prior version carried. That removes one of the more probable Composer conflict sources. It does not change the structural conclusion: path (a) — depend on the core PHPMathML library and write a thin Laravel provider + facade — remains the only realistic route. Path (b), shimming Symfony DI into Laravel, is now harder rather than easier, since a shim would have to emulate Symfony 7 container semantics specifically.

Technical risk — still high, with two signals revised.

• Revised downward: the "no visible release cadence / possible abandonment" concern. A 4.0.0 that drops EOL Symfony versions and adds current-framework support is an active-maintenance signal. Bus factor remains 1, but "dormant" is no longer the right characterization.
• Revised downward: the PHP constraint. A PHP 8.2 floor matches Laravel 11/12 minimums exactly, so there is no runtime conflict and no downgrade pressure on our platform.
• Unchanged: 0 stars, 0 dependents, no production validation, no community bug surface. We would still be the first serious consumer.
• Unchanged: namespace (mercurysolutions) does not match the repository owner (renaudclosset), so upstream lineage is still unclear — and now the divergence matters more, because 4.0.0 is a breaking major we would need to reconcile against whatever fork history exists.
• Unchanged but now more relevant: the 2026-05-22 release-date anomaly from the prior assessment. Treat 4.0.0 as the authoritative current release and re-verify the metadata before trusting any version pin derived from it.

Key questions to resolve before commitment:

1. Does 4.0.0 bump the core PHPMathML library, or is this a bundle-only change? This determines whether we inherit any functional improvement at all when we adopt the core package directly.
2. Does the core library also require PHP 8.2 in lockstep, or does it still support older runtimes? Our integration targets the core, not the bundle, so the bundle's constraint tells us little.
3. What exactly does the bundle add on top of the core library now — config tree, Twig extension, DI aliases? If the 4.0.0 diff is purely container/support-version churn, the adapter cost is unchanged.
4. Are there breaking API changes in 4.0.0 beyond framework support? The changelog lists none, but the diff link should be read directly before we assume a no-op.
5. Presentation vs Content MathML output, and consumer surfaces (browsers, screen readers, PDF pipelines) — unchanged from the prior assessment and still the gating question.
6. Is the maintainer responsive? Still worth a real GitHub issue before building on this.

Integration Approach

Stack fit — none out of the box, unchanged. Symfony 7 compatibility is irrelevant to a Laravel runtime. Laravel has no FrameworkBundle, no Kernel::registerBundles(), no AbstractExtension config tree. The 4.0.0 release updates a surface we do not have.

Migration path — wrap, don't install. Unchanged, and 4.0.0 does not alter the steps:

1. Read the 4.0.0 diff and identify the core package version it pins (composer.json require); depend on that directly.
2. Register a MathMLServiceProvider binding the library's entry class as a singleton.
3. Expose a MathML facade plus a Blade directive or helper (@mathml($expression)) replacing the Twig extension.
4. Move any bundle configuration into config/mathml.php and publish it.
5. Wrap the call site behind our own MathRenderer contract so the library can be swapped without touching domain code.

The contract remains the most important artifact. Math rendering is volatile, and the 4.0.0 release is a reminder that this package's versioning is driven by Symfony's lifecycle, not ours — another reason the interface must be ours.

Compatibility — improved on both hard axes.

• PHP: 8.2 floor aligns with Laravel 11/12. No action required.
• Symfony: ^7 aligns with the Symfony components Laravel 11/12 already ship. Conflict risk is materially lower than the prior version.
• Caveat: dropping Symfony 2/3/4 means the bundle can no longer be installed alongside older Laravel 8/9 estates. Irrelevant while we follow path (a), but it matters if we ever fork-and-vendor the bundle rather than the core.
• Still run composer why-not against our current Laravel minor before writing code, and confirm the core library's own constraint set — the bundle's Symfony 7 requirement does not tell us what the core requires.

Sequencing.

• Week 0 — spike. One engineer, 2–3 days: install the core library at the version 4.0.0 pins, in a scratch Laravel 11/12 app, generate a representative expression, render in target surfaces, document adapter cost. Do not install the bundle.
• Week 1 — decision gate. Proceed if output is clean and no dependency conflicts. Otherwise evaluate MathJax/KaTeX client-side rendering or a headless LaTeX service.
• Week 2+ — build. Adapter, contract, tests, golden-file suite of representative expressions.
• Defer if no roadmap item requires server-side MathML now. The 4.0.0 release does not create urgency.

Operational Impact

Maintenance — assume ownership, with a slightly better upstream signal. 4.0.0 is evidence the maintainer is active, so "assume it is dead" overstates the case; "low-cadence, single-maintainer, framework-lifecycle-driven" is accurate. Budget for fork-and-own anyway: vendor the core library into our namespace if the license permits, or pin an exact version and treat upgrades as projects. Assign a named owner.

Support — none. No SLA, no commercial backing, GitHub issues only. Internal docs and the golden-file suite remain the de facto support artifact. The 4.0.0 changelog is one line plus a diff link — do not expect detailed migration notes at major versions.

Scaling — unchanged. Generation is string assembly; CPU cost negligible and cacheable by expression hash. Downstream risk dominates: output size per page, and renderer compatibility across browsers and assistive tech. Cache rendered fragments at the edge and invalidate on library upgrade.

Failure modes to instrument:

• Malformed XML — silent invalid markup, blank renders, garbled screen-reader output. Validate XML in tests and assert on parse in production.
• PHP floor ratchet — new: 4.0.0 raised the minimum to 8.2. Each major may raise it again, dragging our runtime floor with it if we take upgrades. Pin and upgrade deliberately.
• Forced-framework-upgrade majors — new: 4.0.0's pattern is to drop old Symfony majors on major releases. If we fork, we inherit the obligation to reconcile each such break ourselves.
• Dependency lock-in — a Symfony constraint blocking a future Laravel major. Mitigated by isolating behind our own contract; note this risk is lower now that both ecosystems sit on Symfony 7.
• Renderer drift — browser MathML support or client-side polyfill changes. Maintain a visual regression harness.
• Abandonment — no upstream fix for a spec or security issue. Mitigated by vendoring and a documented fork procedure.
• Accessibility regression — highest severity, because malformed math is invisible to sighted QA and blocking to screen-reader users. Require manual assistive-tech verification, not just snapshots.

Ramp-up — modest, but domain-heavy, unchanged. The library API is small; MathML is not. The team needs Presentation vs Content MathML, browser support boundaries, and a fallback strategy (MathJax/KaTeX, XSLT to SVG). A few days of domain learning beyond the integration work — that cost still dominates the package's own learning curve.

Verdict for a Laravel team — unchanged in direction, softened in risk posture. Treat this as "PHPMathML, self-integrated." 4.0.0 is a positive maintenance signal and removes the two most concrete compatibility objections (PHP version, Symfony conflict), but it delivers nothing to a Laravel consumer and reinforces framework coupling. Adopt only if server-side math generation is on the roadmap now; otherwise defer, and when adopted, spike-and-fork rather than commit to the bundle.