- What is rector/rector-phpoffice and what problem does it solve?
- rector/rector-phpoffice is a Rector ruleset that mechanically rewrites legacy PhpOffice code, primarily PHPExcel calls, into PhpSpreadsheet equivalents. It is a one-shot migration utility rather than a runtime library, so it belongs in require-dev and should be removed once the migration is complete. It handles rote namespace, class, and some method renames but does not resolve semantic differences between the libraries.
- How do I install rector/rector-phpoffice in a Laravel project?
- Install it as a development dependency with Composer alongside Rector, for example composer require --dev rector/rector-phpoffice. Create a dedicated Rector config file such as rector-phpoffice.php so the ruleset is invoked only for the migration, not on every pull request. Confirm the install does not downgrade your existing Rector or PHP constraints before running it.
- Does rector/rector-phpoffice work with Laravel 10 and Laravel 11?
- It is framework-agnostic: the rules operate on PHP ASTs and do not register a Laravel service provider, so Laravel 10 or 11 is not the main compatibility constraint. What matters is the PHP version and the Rector major version required by the ruleset. Run it on a branch and verify against your app's actual spreadsheet code rather than assuming Laravel version support.
- Can rector/rector-phpoffice fully automate a PHPExcel to PhpSpreadsheet migration?
- No. It reliably handles the mechanical subset, such as namespace changes from PHPExcel_* to PhpSpreadsheet and many class or method renames, which may remove roughly 40 to 60 percent of the rote work. It cannot fix semantic differences in date and time handling, cell value binding, style cloning, formula calculation, or reader and writer options. Those changes can produce valid code that behaves incorrectly, so each diff needs review and hand-fixing.
- Is it safe to run rector/rector-phpoffice in CI or against production code?
- Treat the ruleset as unvetted third-party code: it has zero stars, zero dependents, and a score of zero, and Rector rules run with write access over your full source tree. Run it in dry-run mode first, inspect the generated diffs, and avoid adding it to a CI pipeline that executes on every pull request. Many teams vendor or fork the rule classes internally rather than depending on Packagist long term.
- Which PHPExcel and PhpSpreadsheet versions does this ruleset target?
- The ruleset is built to translate legacy PHPExcel API usage toward PhpSpreadsheet equivalents, but the exact version scope should be verified in its composer.json and against your installed packages. Confirm which PHPExcel version you are migrating from and which PhpSpreadsheet version you are targeting before trusting the output. If the versions do not match, expect more manual fixes and validate with a regression test suite.
- How do I run only the PhpOffice rules and not my other Rector sets?
- Put the ruleset in its own config file, for example rector-phpoffice.php, and invoke Rector with that config explicitly instead of adding it to your default rector.php. This keeps a one-time migration from running on every PR forever. It also lets you scope runs to specific paths or modules during an incremental migration.
- Why did Rector leave some PHPExcel code unchanged after running the ruleset?
- Rector fails quietly on code it does not recognize, so files using spreadsheet APIs in atypical ways may be skipped without an error. That can leave a mixed PHPExcel and PhpSpreadsheet codebase that looks migrated until runtime. Grep for remaining PHPExcel references, review diff coverage, and handle skipped call sites manually or with custom rules.
- How should I test a PHPExcel to PhpSpreadsheet migration?
- Build a regression harness before applying the ruleset, exercising every spreadsheet entry point and comparing output cell values, types, formats, formulas, and merged ranges against fixtures generated by the legacy code. Compare generated .xlsx files byte-for-byte where practical, or cell-for-cell when timing and metadata make byte comparison unreliable. Migrate module by module and soak each one behind existing tests before moving on.
- Is rector/rector-phpoffice maintained, and what are the alternatives?
- Given zero stars, zero dependents, and a score of zero, do not assume active maintenance; if you adopt it, fork or vendor the rules you need and own them internally. Alternatives include the official PhpSpreadsheet migration guidance, manual refactoring supported by your regression tests, and writing targeted custom Rector rules for your own call sites. The completion signal is removing PHPExcel from composer.json, not simply running Rector once.