- How do I install typo3/class-alias-loader in a Laravel app?
- Require the package with Composer and add an allow-plugins entry if you are on Composer 2.2 or newer. Declare your alias map files in the extra block of the root composer.json, then run composer dump-autoload. No Laravel service provider or application code changes are needed. If aliases must work at runtime, install it as a production dependency rather than require-dev.
- Does typo3/class-alias-loader replace Laravel config/app.php aliases?
- No. Laravel's AliasLoader maps short names to facade classes, while this package handles fully-qualified old-to-new class name renames. The two systems are orthogonal, but they can collide if both register the same alias. Do not use it as a way to remove facade aliases from config/app.php.
- How do I configure class alias maps in composer.json?
- Add an extra block with the key typo3/class-alias-loader and a class-alias-maps array pointing to PHP files. Each map file must return an associative array where keys are old class names and values are new class names. After editing the maps, run composer dump-autoload so the loader can pick them up.
- Does typo3/class-alias-loader work with Laravel 10, 11, or 12?
- It is a framework-agnostic Composer plugin, so Laravel version is not the main constraint. It works anywhere Composer autoloading is used, including modern Laravel releases, provided your Composer and PHP versions are compatible. The plugin does not register a Laravel service provider or integrate with Laravel-specific features.
- Why do I need to allow typo3/class-alias-loader in Composer 2.2+?
- Composer requires explicit approval for plugins that modify autoloading behavior. Add an allow-plugins entry for typo3/class-alias-loader set to true in your composer.json config. Without that approval the plugin will not run, and your alias maps will not be registered.
- Is it safe to install typo3/class-alias-loader in production?
- The package is a no-op when no alias maps exist, so adding it is usually low risk. The main production concern is that it rewrites vendor/autoload.php during dump-autoload, which conflicts with immutable vendor directories, read-only mounts, or installs run with --no-scripts. Install it as a production dependency if runtime aliases are required.
- How is this different from calling class_alias() in bootstrap/app.php?
- Functionally, both provide lazy alias resolution for old class names. The difference is that alias maps can ship inside a library's composer.json extra block, so consumers get compatibility without writing glue code in their application. You can still call class_alias() manually for renames that only affect your own codebase.
- Does typo3/class-alias-loader help with serialized queued jobs or morph maps after a class rename?
- Its public ClassAliasMap::getClassNameForAlias() method can be useful for normalizing string-based class references. That includes Eloquent morph map values and queued job class names that are resolved as strings. However, the plugin does not automatically rewrite strings already persisted in databases or serialized payloads.
- Will PHPStan, Psalm, or my IDE understand old class names registered by this plugin?
- No, aliases are runtime-only. Static analysis tools, IDE navigation, optimized classmaps, and OPcache preloading see only the new class names. PHPStan or Psalm will typically report the old names as nonexistent unless you add stubs or ignore rules.
- Is typo3/class-alias-loader actively maintained, and what are the alternatives?
- The package has a small maintainer base in the TYPO3 ecosystem and a low dependent count, so you should pin versions carefully and verify release history. Version 2.0.0 removed case-insensitive loading and 2.0.1 was a critical bugfix, which shows the autoload path has had real regressions. Alternatives include manual class_alias() calls in bootstrap/app.php, a files autoload entry, or compatibility wrapper classes you maintain yourself.