Common Laravel Package

Product Decisions This Supports

• Build vs. buy for binary/legacy document I/O. phpoffice/common is the low-level foundation that PhpSpreadsheet and PHPWord sit on (OLE compound-document reading, XML writer/reader helpers, drawing primitives). It is almost never a direct dependency decision — it's a decision you inherit when you approve PhpSpreadsheet/PHPWord. Treat it as part of the "document processing" line item, not a separate vendor evaluation.
• Release 1.1.0 unlocks a new capability: OLEWrite. Until now the package could only read OLE2 compound documents (the container format behind legacy .xls, .doc, .ppt, .msg, .msi). 1.1.0 adds the write counterpart. This is the first genuinely product-relevant change in the 1.0.x → 1.1.0 line and opens up workflows that previously required a commercial library or hand-rolled binary assembly: generating legacy-format containers, embedding/attaching streams into OLE documents, templating .xls/.msg-style files. Scope it as an experiment, not a committed roadmap item — it is brand new in this release with no track record.
• Roadmap input: legacy/interop export formats. If customers or partners ask for "real Excel 97-2003 (.xls)" export, Outlook .msg generation, or embedded-object support, OLEWrite is now a plausible low-cost path worth a spike (1-2 dev days) before you price out Aspose or similar.
• Platform currency / upgrade risk management. PHP 8.5 has been added to the CI matrix. That means the package (and by extension PhpSpreadsheet/PHPWord) is tracking the PHP release train. This de-risks your own PHP upgrade planning: you can tell engineering "the spreadsheet stack is 8.5-ready" rather than discovering a hard blocker mid-upgrade.
• Engineering quality signal, not a feature. PHPStan raised to level 7 and PHPStan 2.x allowed. Relevant if your own CI runs static analysis over vendor/ or if you ship a fork. It is a credibility data point when justifying "keep using the OSS stack" over a commercial license.
• Use cases to green-light: server-side report/spreadsheet generation, importing customer-uploaded legacy Office files, document templating, data migration off legacy binary formats.

When to Consider This Package

• Adopt (transitively) when you are already using PhpSpreadsheet or PHPWord and simply need to keep the dependency tree current. No action beyond a composer update; 1.1.0 is additive with no breaking changes, no deprecations, and no version-constraint changes.
• Adopt directly when you need to read or write OLE2 compound-document containers without pulling in a full spreadsheet engine — e.g., extracting embedded streams, inspecting .msg/.msi-like files, or assembling a binary Office container yourself.
• Trial OLEWrite specifically when a legacy-format export requirement exists and you want to avoid a commercial license. Set an explicit evaluation gate: does it round-trip against real files, does it handle your target consumer (Excel 2003, Outlook, a third-party parser), and what is the fallback if the maintainers change direction? Newly landed code in a low-velocity library deserves that scrutiny.
• Look elsewhere when:
  • You only need modern formats (.xlsx, .docx, .pptx, CSV, PDF) — this library is not the entry point; use PhpSpreadsheet/PHPWord directly.
  • You need an SLA, indemnification, or vendor support — PHPOffice is volunteer-maintained; commercial alternatives (Aspose, Syncfusion, Apryse) exist for a reason.
  • You need high-volume or streaming OLE writing today — OLEWrite has no maturity history yet; benchmark before committing.
  • You cannot accept a transitive dependency in your tree at all — in that case you're not really choosing this package, you're choosing against the whole PHPOffice stack.
• Watch for: release cadence is slow and feature-driven (1.0.5 → 1.1.0 with four small PRs, two first-time contributors). Treat the project as stable-but-quiet infrastructure rather than actively evolving. Pin versions and be prepared to fork if a bug blocks you.

How to Pitch It (Stakeholders)

For executives (one paragraph): The PHPOffice stack is the free, open-source engine we use to read and write Office documents. Its foundational library, phpoffice/common, just shipped 1.1.0 — a small, non-breaking release that (a) adds the ability to write legacy Microsoft compound-document files, not just read them, and (b) confirms the stack runs on PHP 8.5, the next PHP version we'll be upgrading to. Two consequences: we have a low-cost option for legacy .xls/.msg-style export requests that we'd otherwise license commercially, and the PHP 8.5 upgrade has one less blocker. No migration work, no licensing cost, no action required beyond a routine dependency update. Risk is low; the write feature is new, so we'd validate it with a short spike before promising it to customers.

For engineering (short version): phpoffice/common 1.1.0 is additive — PHP 8.5 added to CI, PHPStan bumped to level 7 and allowed at 2.x, and a new OLEWrite class as the counterpart to OLERead. No breaking changes, no deprecations, no constraint changes. Safe to bump. If you touch OLEWrite, note it's fresh code with a single contributor and no test history beyond this release — wrap it behind an interface and keep OLERead-only paths untouched.