- Can I use ssch/typo3-rector in a Laravel project?
- This package is *exclusively* for TYPO3 codebases. While you can install it in a Laravel project, it won’t work with Laravel’s dependency injection (Symfony’s PSR-11 container) or Eloquent migrations. Use it only if you’re maintaining TYPO3 extensions or shared PHP files alongside Laravel.
- How do I install ssch/typo3-rector in a Laravel project?
- Run `composer require --dev ssch/typo3-rector` in your Laravel project’s root. However, avoid running it on Laravel files—configure it to target only TYPO3-specific directories (e.g., `typo3-legacy/`) using the `paths` option in `rector.php`.
- Will this break my Laravel application if I run it on the entire codebase?
- Yes, it will likely break Laravel code. The package targets TYPO3-specific patterns like `GeneralUtility::makeInstance()` or `ExtensionManagementUtility`, which don’t exist in Laravel. Always run it in `--dry-run` mode first and restrict it to TYPO3-only directories.
- Does ssch/typo3-rector support Laravel’s Blade templates or Eloquent models?
- No, this package has no rules for Blade templates, Eloquent, or Laravel’s service container. It’s designed for TYPO3’s `ext_tables.sql`, TypoScript, and `GeneralUtility` patterns. For Laravel-specific refactoring, use `rector/rector` with Laravel-compatible rules instead.
- How do I exclude Laravel files from TYPO3 Rector’s processing?
- In your `rector.php`, define `paths` to include only TYPO3 directories (e.g., `paths: [typo3-extensions/]`). Alternatively, exclude Laravel namespaces using rule configurations like `$rectorConfig->ruleWithConfiguration(GeneralUtilityMakeInstanceToConstructorPropertyRector::class, ['exclude' => ['App\']])`.
- Is ssch/typo3-rector safe to run in production?
- Absolutely not. The package’s documentation explicitly warns against running it in production. Always test changes in a staging environment with `--dry-run` and review the diffs before deploying. Automated refactoring can introduce subtle bugs.
- What Laravel alternatives exist for automated PHP refactoring?
- For Laravel projects, use `rector/rector` (core package) with rules like `RectorLaravel` or `RectorSymfony`. For coding standards, `php-cs-fixer` is a better fit. If migrating from TYPO3 to Laravel, manual refactoring or custom Rector rules are required—this package won’t bridge the gap.
- Can I use ssch/typo3-rector to migrate a TYPO3 extension to Laravel?
- No, this tool won’t help. It’s designed for *within* TYPO3 (e.g., upgrading from TYPO3 v10 to v12). To migrate a TYPO3 extension to Laravel, rewrite the core logic manually or create custom Rector rules targeting Laravel’s `app()->make()` or dependency injection instead of `GeneralUtility`.
- How do I configure ssch/typo3-rector for a mixed Laravel/TYPO3 codebase?
- Isolate TYPO3 code into a subdirectory (e.g., `typo3/`) and configure Rector to process only that path in `rector.php`. Disable TYPO3-specific rules that conflict with Laravel (e.g., `ExtEmConfRector`) and test thoroughly. Use `--dry-run` to preview changes before applying them.
- What PHP versions does ssch/typo3-rector support, and will it work with Laravel’s PHP requirements?
- The package supports PHP 7.4+. Laravel typically requires PHP 8.0+, so version conflicts are unlikely. However, Laravel’s autoloading (PSR-4) may clash with TYPO3’s class aliasing (e.g., `t3lib_div` → `GeneralUtility`). Test in a staging environment first.