Html To Spreadsheet Bundle Laravel Package

Product Decisions This Supports

• Shipping an "Export to Excel/CSV/ODS" feature without building one. The recurring request from finance, ops, and B2B customers is "give me my data in a spreadsheet." This package turns that from an engineering epic (PhpSpreadsheet styling, merges, freeze panes, column widths, comments, images, hyperlinks) into a template-authoring task.
• Build vs. buy on report rendering. If your product already renders HTML/Twig views, the cheapest path to styled spreadsheets is to reuse that rendering muscle instead of standing up a separate report engine. This package is the "buy" (MIT, one composer line) that beats a 2–4 week internal build.
• Letting non-engineers own report layout. Because layout is declarative HTML with data-xls-* attributes, an ops analyst or designer can iterate on a report template without touching PHP. That's a roadmap-unlocking capability: you can promise "custom exports" as a configurable feature rather than a bespoke services engagement.
• Multi-format compliance and hand-off. XLSX for internal analysis, CSV for data pipelines, ODS for public-sector/LibreOffice users — one template, three outputs. Useful for procurement requirements that specify an open format.
• De-risking a legacy Excel-template migration. Teams on aging .xls templates or macro-driven exports get a modern, version-controlled, testable representation with strict mode to catch template errors in CI.
• Prioritizing the "reporting polish" backlog. Conditional formatting, cell comments/approvals, locked cells, and hyperlinks are usually the long tail of low-value tickets that never get scheduled. Here they're attributes — so a single spike can clear several quarters of "nice to have" requests.
• Internal admin/back-office tooling. Low-traffic, high-value exports (statements, invoices, reconciliation sheets, onboarding packs) are the sweet spot: small payloads, heavy formatting, high stakeholder visibility.

When to Consider This Package

Consider it when all of these hold:

• You are on Symfony 6.4/7.x/8.x with PHP 8.2+ and already have Twig in the stack. The README is explicit — this is a Symfony bundle, not a Laravel package. In Laravel you'd be consuming the underlying renderer classes manually, with no service provider, no facade, no config publishing. That's a real integration cost, not a footnote.
• Your exports are tabular and formatting-heavy but computationally simple: hundreds to low thousands of rows, styled headers, merges, money/date formats, conditional highlighting, comments, links.
• You want PhpSpreadsheet 4.x/5.x behavior without letting PhpSpreadsheet's imperative API leak across your codebase.
• Your team is comfortable with a "draft" maturity dependency and can absorb a bug or two, or pin a version and vendor the renderer.
• You value French-oriented presets (money, date, percent2) — a genuine time-saver for FR/EU locales, and a signal the author built this for real European finance reporting.

Look elsewhere when:

• You're Laravel-first. Laravel Excel / PhpSpreadsheet wrappers have far larger communities, better docs, and Laravel idioms. Choosing this means owning the glue.
• The export is a data pipeline, not a document. Large datasets, streaming, chunked writes, >10k rows: HTML-in-memory parsing plus PhpSpreadsheet is the wrong shape. Use a streaming writer.
• You need charts, pivot tables, slicers, or genuine Excel templates. Not in the feature list.
• Adoption signals matter to your org. 7 stars, 0 dependents, single maintainer, self-described "first draft, WIP." There is no community to fall back on if the maintainer stops. That's a supportability decision, and it belongs on the record.
• You have hard SLAs, audit trails, or security review requirements around third-party code (e.g., remote image fetching from data-xls-image URLs is an SSRF surface you must govern).
• You just need CSV. Don't take a spreadsheet dependency to write comma-separated values.

Mitigation if you adopt anyway: wrap it behind your own SpreadsheetExporter interface, pin the version, keep templates in your repo (not the vendor dist file), and add a smoke test per template. That caps the blast radius to hours, not weeks, if it's abandoned.

How to Pitch It (Stakeholders)

To executives: We can deliver the spreadsheet-export capability customers keep asking for in roughly a sprint instead of a quarter. It's MIT-licensed, one dependency, and it reuses the templating we already have — so the reports look like our product, not a raw data dump. Total cost of ownership is low, and because layout lives in templates rather than code, future report variations are a configuration change, not an engineering project. The trade-off is honestly stated: it's a young, single-maintainer open-source package with a small user base. We mitigate that by wrapping it in a thin internal interface so we can swap it out without touching product code. My recommendation: adopt for internal and mid-tier reporting now, keep it out of any contractual SLA path until we've run it for a quarter.

To engineering: It's a Symfony bundle that turns annotated HTML tables into XLSX/ODS/CSV via PhpSpreadsheet — you write <td data-xls-bg-color="#E7E6E6" data-xls-conditional="value<0|bg:FFCCCC"> instead of a hundred lines of getStyle()->applyFromArray(). One-liner controller integration via a trait or SpreadsheetRenderer service. Requires PHP 8.2+, Symfony 6.4+, PhpSpreadsheet 4/5. Caveats: it's a WIP first draft, 7 stars, no dependents, so treat the API as unstable — pin the version, write template smoke tests, enable strict: true so bad attributes fail in CI rather than in a customer's download, and don't let the data-xls-image remote-URL fetch reach user-controlled input without an allowlist. Estimated integration: half a day for a first report, one to two days to productionize with tests and the adapter wrapper.