phoneburner / composer-replacements
A 'no-op' Composer dependency used to cleanly replace other packages and unneeded polyfills
Installs: 116
Dependents: 6
Suggesters: 0
Security: 0
Stars: 0
Watchers: 2
Forks: 1
Open Issues: 0
Language:Dockerfile
Requires
- php: ^8.4.0
- ext-ctype: *
- ext-iconv: *
- ext-intl: *
- ext-mbstring: *
- ext-random: *
- ext-sodium: *
Replaces
- paragonie/random_compat: >=v2.0.0
- paragonie/sodium_compat: *
- symfony/polyfill-ctype: *
- symfony/polyfill-iconv: *
- symfony/polyfill-intl-grapheme: *
- symfony/polyfill-intl-icu: *
- symfony/polyfill-intl-idn: *
- symfony/polyfill-intl-messageformatter: *
- symfony/polyfill-intl-normalizer: *
- symfony/polyfill-mbstring: *
- symfony/polyfill-php72: *
- symfony/polyfill-php73: *
- symfony/polyfill-php80: *
- symfony/polyfill-php81: *
- symfony/polyfill-php82: *
- symfony/polyfill-php83: *
- symfony/polyfill-php84: *
README
A 'no-op' Composer package used to cleanly replace other dependencies and unneeded polyfills.
Why replace safe polyfill packages like symfony/polyfill-php84
?
- A root project that depends on this library is guaranteed to be on PHP 8.4 or later, due to this library's version
constraints. If some other dependency of the root project requires the
symfony/polyfill-php84
package, that package is completely unnecessary and adds overhead to every request. That overhead is very slight, especially when opcache is enabled, but it exists nevertheless. Polyfills usually have some kind of "bootstrap.php" file configured to always load and execute when Composer initializes autoloading. Ideally, polyfill libraries minimize their performance impact with some kind of early return conditional that checks for the PHP version or existence of a particular extension. - Because they could define methods in the global namespace, even though the definition code would never execute at runtime, unneeded polyfills can complicate static analysis and IDE tooling. Beyond simple "multiple definitions exist" warnings, nothing enforces a polyfill method to have the same signature as method it covers.
- Unneeded packages are unnecessary downloads when building production images and have dependency constraints that Composer has to manage. These are additional potential points of failure.
Why require this package instead of defining replacements in the root?
- Repeatability across multiple projects.
- Requiring this library as a dev dependency does not other affect packages that require it. This is most useful for frameworks and framework-like packages where the library has complex behavior and testing.
- The output of Composer commands that produce tree output is significantly cleaner, especially if also run recursively.
docker run --rm -it -v $PWD:/app -u $(id -u):$(id -g) composer/composer install --ignore-platform-reqs