Skip to content

Filesystem hard-depends on ext-mbstring polyfill that may not be required #60444

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
dktapps opened this issue May 17, 2025 · 6 comments
Closed

Filesystem hard-depends on ext-mbstring polyfill that may not be required #60444

dktapps opened this issue May 17, 2025 · 6 comments
Labels
Bug Filesystem Status: Needs Review

Comments

@dktapps
Copy link

dktapps commented May 17, 2025 •
edited
Loading

Symfony version(s) affected

6.4.13

Description

symfony/src/Symfony/Component/Filesystem/composer.json

Line 21 in 94f4d7a

"symfony/polyfill-mbstring": "~1.8"

This dependency pulls in symfony/polyfill-mbstring even when ext-mbstring is already present.

Until recently, this was fine (the polyfill was just dead weight), but polyfill-mbstring recently added a hard dependency to ext-iconv which is not typically present in my application's environment. However, ext-mbstring is available. So my CI suddenly started having issues with ext-iconv being required by a polyfill which my environment doesn't actually call for anyway.

How to reproduce

  • Have a PHP binary which has ext-mbstring but not ext-iconv
  • Install symfony/filesystem using Composer
  • Composer now bails out saying this:
Your lock file does not contain a compatible set of packages. Please run composer update.

  Problem 1
    - symfony/polyfill-mbstring is locked to version v1.32.0 and an update of this package was not requested.
    - symfony/polyfill-mbstring v1.32.0 requires ext-iconv * -> it is missing from your system. Install or enable PHP's iconv extension.
  Problem 2
    - symfony/filesystem is locked to version v6.4.13 and an update of this package was not requested.
    - symfony/filesystem v6.4.13 requires symfony/polyfill-mbstring ~1.8 -> satisfiable by symfony/polyfill-mbstring[v1.32.0].
    - symfony/polyfill-mbstring v1.32.0 requires ext-iconv * -> it is missing from your system. Install or enable PHP's iconv extension.

To enable extensions, verify that they are enabled in your .ini files:
    - /home/runner/work/PocketMine-MP/PocketMine-MP/bin/bin/php7/bin/php.ini
You can also run `php --ini` in a terminal to see which files are used by PHP in CLI mode.
Alternatively, you can run Composer with `--ignore-platform-req=ext-iconv` to temporarily ignore these required extensions.

Possible Solution

Depend on ext-mbstring in symfony/filesystem instead of symfony/polyfill-mbstring.
symfony/polyfill-mbstring already provides ext-mbstring anyway so this should be fine.

Additional Context

No response
@dktapps dktapps added the Bug label May 17, 2025
@MatTheCat
Copy link
Contributor

Have a look at https://php.watch/articles/composer-replace-polyfills since your environment provides ext-mbstring this would be better than requiring the iconv polyfill.

@dktapps
Copy link
Author

dktapps commented May 17, 2025

Have a look at https://php.watch/articles/composer-replace-polyfills since your environment provides ext-mbstring this would be better than requiring the iconv polyfill.

Yep, this is what I did 👍🏻

@chalasr
Copy link
Member

chalasr commented May 17, 2025

Nothing to do here I think as requiring polyfills provide a smooth experience when those extensions are missing, they do nothing when the extensions are present, and can be avoided as said above.

@dktapps
Copy link
Author

dktapps commented May 17, 2025

I had no problem with the (unncessary) polyfill being present until it started requiring iconv.

Is there not a way to have Composer understand that the polyfill isn't needed, automatically?

@xabbuh
Copy link
Member

xabbuh commented May 17, 2025

Looking at the error it seems that you generated the composer.lock file on a system that had the iconv extension installed. That’s why a version of the polyfill depending on it was able to end up in your lock file. The issue is that your CI does not seem to have the same setup as the system the lock file was generated on.

@xabbuh
Copy link
Member

xabbuh commented May 19, 2025

closing as explained, thank you for understanding

@xabbuh xabbuh closed this as not planned Won't fix, can't repro, duplicate, stale May 19, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Bug Filesystem Status: Needs Review
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@MatTheCat @xabbuh @chalasr @carsonbot @dktapps