Rector Phpoffice Laravel Package

Product Decisions This Supports

• Roadmap sequencing for platform upgrades. PHPExcel/PHPOffice has been abandoned since 2017 and is a recurring blocker in PHP 8.x and Laravel upgrade initiatives. This package turns "we can't upgrade because of the Excel export layer" into a scoped, estimable work item, which is the input a roadmap decision actually needs.
• Build vs. buy vs. hand-migrate. The three options are: hand-migrate every call site, write our own codemod, or adopt an existing Rector ruleset. This package is the third option, and a cheap one to trial — a spike can be timeboxed to a day and produces a concrete diff to compare against a manual estimate. It wraps Rector core, so most of the engineering leverage comes from Rector itself; the rules are the domain-specific layer on top.
• Feature-level go/no-go on legacy reporting modules. Excel/CSV export code is usually high-value, low-glamour, and barely tested. If a module must be touched for compliance, dependency hygiene, or a framework upgrade, this package determines whether that work is a mechanical refactor or a rewrite — a materially different budget conversation.
• Incremental adoption strategy. Because Rector rules can be enabled one at a time in a config file, this supports a "migrate alongside feature work" plan rather than a big-bang rewrite branch. That is a schedule and headcount decision, not just a technical one.
• Tech-debt and due-diligence assessments. For an acquisition or a portfolio review, running this ruleset dry-run against a codebase is a fast, quantified proxy for how much legacy spreadsheet code exists and how mechanical the cleanup would be.
• Agency and multi-app portfolio triage. Teams maintaining many Laravel applications can apply the same ruleset repeatedly, which changes the economics of accepting legacy maintenance contracts.

When to Consider This Package

Consider it when:

• You own PHP code with direct PHPExcel/PHPOffice usage and are moving to PhpSpreadsheet as part of a broader PHP or framework upgrade.
• You have a test suite, or at minimum static analysis and a disciplined review process, to validate automated refactors before merge.
• The usage is broad enough that manual find-and-replace is tedious — dozens of files, many PHPExcel_* class references, getActiveSheet, writer/reader instantiations.
• You already run Rector in CI, so the marginal setup cost is a config entry and a dev dependency.
• You want the migration to be reviewable as small, per-rule diffs rather than one opaque branch.

Look elsewhere or proceed with heavy caution when:

• Provenance matters. Zero stars, zero dependents, and no community validation is a real signal. Treat it as unvetted sample code: read the rules, pin the version or vendor a fork, and do not add it to a production runtime dependency list (it belongs in require-dev only).
• You use maatwebsite/excel or similar. Those packages already abstract PhpSpreadsheet; the migration problem may not exist in your codebase at all.
• The footprint is small. Under roughly ten files, a manual migration is cheaper than introducing a tool, a config, and a review process.
• You need complete API coverage. Community rule sets are typically partial and target the common classes and method renames. Assume a manual tail and budget for it; verify coverage against your actual symbol usage before committing to a date.
• You can't run automated refactors safely — no tests, no clean VCS state, no ability to review generated diffs.
• You're greenfield or already on PhpSpreadsheet. Not applicable.

How to Pitch It (Stakeholders)

For executives: The PHPExcel library we depend on for spreadsheet exports has been abandoned for years, and it is one of the things standing between us and a supported PHP/framework version. This package is not a new product dependency — it is a developer-only tool that mechanically rewrites the old spreadsheet code into its supported successor, the way a find-and-replace does but with an understanding of the code's structure. It is cheap to trial, produces a reviewable diff rather than a rewrite, and can be thrown away if it doesn't pay off. The pitch is not "adopt this package"; it is "let's spend a day measuring whether this package converts an unavoidable upgrade cost into a much smaller one." Given its immaturity, we would trial it on a branch, keep it out of production dependencies, and assume some manual cleanup remains.

For engineering: It's a Rector ruleset that codifies the PHPExcel → PhpSpreadsheet migration: class renames, namespace changes, writer/reader factory updates, and the common method-level differences. It runs as a dev dependency against a rules config, so we can enable rules incrementally and land small diffs instead of one enormous branch. Two caveats to plan around. First, it is unmaintained and unvalidated — no stars, no dependents — so we should read the rule definitions, pin or vendor it, and not assume completeness. Second, Rector produces syntactically valid but semantically unverified changes; the test suite is the actual safety net, and anything without coverage gets a manual pass. Recommended path: dry-run on a branch, diff the output, estimate the residual manual work, then decide between this, a hand-written codemod, and manual migration on cost alone.