fotobank / strauss
Changes the class namespaces from vendor and moves all dependencies to a separate directory inside the WordPress plugin.
Installs: 5
Dependents: 0
Suggesters: 0
Security: 0
Stars: 0
Watchers: 0
Forks: 59
pkg:composer/fotobank/strauss
Requires
- composer/composer: *
- json-mapper/json-mapper: ^2.2
- league/flysystem: ^1.0
- symfony/console: ^4|^5
- symfony/finder: ^4|^5
Requires (Dev)
- php: ^7.4|^8.0
- ext-json: *
- clue/phar-composer: ^1.2
- jaschilz/php-coverage-badger: ^2.0
- mheap/phpunit-github-actions-printer: ^1.4
- phpunit/phpunit: ^9
- squizlabs/php_codesniffer: ^3.5
Replaces
This package is auto-updated.
Last update: 2025-10-12 19:34:38 UTC
README
A tool to prefix namespaces and classnames in PHP files to avoid autoloading collisions.
A fork of Strauss for Composer for PHP.
The primary use case is WordPress plugins, where different plugins active in a single WordPress install could each include different versions of the same library. The version of the class loaded would be whichever plugin registered the autoloader first, and all subsequent instantiations of the class will use that version, with potentially unpredictable behaviour and missing functionality.
Breaking Changes
- v0.14.1 – fixed bugs with file paths in Windows, fixes according to the master branch BrianHenryIE/strauss
- v0.14.0 –
psr/*packages no longer excluded by default - v0.12.0 – default output
target_directorychanges fromstrausstovendor-prefixed
Use
Require as normal with Composer:
composer require --dev fotobank/strauss
and use vendor/bin/strauss to execute.
Or, download strauss.phar from releases,
curl -o strauss.phar -L -C - https://github.com/fotobank/strauss/releases/download/0.14.1/strauss.phar
Then run it from the root of your project folder using php strauss.phar.
Its use should be automated in Composer scripts.
"scripts": { "strauss": [ "vendor/bin/strauss" ], "post-install-cmd": [ "@strauss" ], "post-update-cmd": [ "@strauss" ] }
or
"scripts": { "strauss": [ "@php strauss.phar" ] }
Configuration
Strauss potentially requires zero configuration, but likely you'll want to customize a little, by adding in your composer.json an extra/strauss object. The following is the default config, where the namespace_prefix and classmap_prefix are determined from your composer.json's autoload or name key and packages is determined from the require key:
"extra": { "strauss": { "target_directory": "vendor-prefixed", "namespace_prefix": "AlexSoft\\My_Project\\", "classmap_prefix": "AlexSoft_My_Project_", "constant_prefix": "ASMP_", "packages": [ ], "override_autoload": { }, "exclude_from_copy": { "packages": [ ], "namespaces": [ ], "file_patterns": [ ] }, "exclude_from_prefix": { "packages": [ ], "namespaces": [ ], "file_patterns": [ "/^psr.*$/" ] }, "namespace_replacement_patterns" : { }, "delete_vendor_packages": false "delete_vendor_files": false, } },
The following configuration is inferred:
target_directorydefines the directory the files will be copied to, defaultvendor-prefixednamespace_prefixdefines the default string to prefix each namespace withclassmap_prefixdefines the default string to prefix class names in the global namespacepackagesis the list of packages to process. If absent, all packages in therequirekey of yourcomposer.jsonare includedclassmap_outputis aboolto decide if Strauss will createautoload-classmap.phpandautoload.php. If it is not set, it isfalseiftarget_directoryis in your project'sautoloadkey,trueotherwise.
The following configuration is default:
delete_vendor_packages:falsea boolean flag to indicate if the packages' vendor directories should be deleted after being processed. It defaults to false, so any destructive change is opt-in.delete_vendor_files:falsea boolean flag to indicate if files copied from the packages' vendor directories should be deleted after being processed. It defaults to false, so any destructive change is opt-in. This is maybe deprecated! Is there any use to this that is more appropriate thandelete_vendor_packages?exclude_from_prefix/file_patternsinclude_modified_dateis aboolto decide if Strauss should include a date in the (phpdoc) header written to modified files. Defaults totrue.include_authoris aboolto decide if Strauss should include the author name in the (phpdoc) header written to modified files. Defaults totrue.
The rest of the configuration:
constant_prefixis fordefine( "A_CONSTANT", value );->define( "MY_PREFIX_A_CONSTANT", value );. If it is empty, constants are not prefixed (this may change to an inferred value).override_autoloada dictionary, keyed with the package names, of autoload settings to replace those in the original packages'composer.jsonautoloadproperty.exclude_from_copypackagesarray of package names to be skippednamespacesarray of namespaces to skip (exact match from the package autoload keys)file_patternsarray of regex patterns to check filenames against (including vendor relative path) where Strauss will skip that file if there is a match
exclude_from_prefixpackagesarray of package names to exclude from prefixing.namespacesarray of exact match namespaces to exclude (i.e. not substring/parent namespaces)
namespace_replacement_patternsa dictionary to use inpreg_replaceinstead of prefixing withnamespace_prefix.
Autoloading
Strauss uses Composer's own tools to generate a classmap file in the target_directory and creates an autoload.php alongside it, so in many projects autoloading is just a matter of:
require_once __DIR__ . '/vendor-prefixed/autoload.php';
If you prefer to use Composer's autoloader, add your target_directory (default vendor-prefixed) to your autoload classmap and Strauss will not create its own autoload.php when run. Then run composer dump-autoload to include the newly copied and prefixed files in Composer's own classmap.
"autoload": {
"classmap": [
"vendor-prefixed/"
]
},
Motivation & Comparison to Mozart
Benefits over Mozart:
- A single output directory whose structure matches source vendor directory structure (conceptually easier than Mozart's independent
classmap_directoryanddep_directory) - A generated
autoload.phptoincludein your project (analogous to Composer'svendor/autoload.php) - Handles
filesautoloaders – and any autoloaders that Composer itself recognises, since Strauss uses Composer's own tooling to parse the packages - Zero configuration – Strauss infers sensible defaults from your
composer.json - No destructive defaults –
delete_vendor_filesdefaults tofalse, so any destruction is explicitly opt-in - Licence files are included and PHP file headers are edited to adhere to licence requirements around modifications. My understanding is that re-distributing code that Mozart has handled is non-compliant with most open source licences – illegal!
- Extensively tested – PhpUnit tests have been written to validate that many of Mozart's bugs are not present in Strauss
- More configuration options – allowing exclusions in copying and editing files, and allowing specific/multiple namespace renaming
- Respects
composer.jsonvendor-dirconfiguration - Prefixes constants (
define) - Handles meta-packages and virtual-packages
Strauss will read the Mozart configuration from your composer.json to enable a seamless migration.
Acknowledgements
Coen Jacobs, Brian Henry and all the contributors to Mozart, particularly those who wrote nice issues.