[RFC] Split the Intl polyfill from the Intl CLDR features #37758
Description
Description
The symfony/intl package provides 2 independent sets of features:
- polyfills for various
ext-intlclasses exposing ICU features (IntlDateFormatter,IntlNumberFormatter,CollatorandLocale) - public APIs exposing some CLDR data that is not available through
ext-intl. That's the\Symfony\Component\Intl\Intlclass in older Symfony versions, and its replacements in newer versions (\Symfony\Component\Intl\{Currencies,Locales,Locale,Languages,Countries,Scripts,Timezones})
When we created the symfony polyfills (many years later), we created a symfony/polyfill-intl-icu, which is semantically meant to provide the first half, but is actually implemented by requiring symfony/intl. This has several effects:
- it does not make it clear what the intended usage is (in the modern way, packages needing only polyfills for ICU classes should depend on
symfony/polyfill-intl-icu) - packages requiring
symfony/polyfill-intl-icuactually receive the fullsymfony/intlpackage, which is by far the biggest contributor to the size of vendors among Symfony components (and bigger than many packages in the ecosystem) due to the size of the CLDR data, which is not needed for their use case. - polyfills are using a very specific architecture (all the implementation goes in an internal abstract class used as parent), which is very common in
symfony/polyfillsbut can be confusing when finding it insymfony/symfony(see [Intl] IntlDateFormatter is abstract, yet it promotes instantiation #37756 for instance, which is caused by such confusion) - if you use the
replacetrick to remove unnecessary polyfills because your project has a requirement onext-intl, you will still get the polyfill implementation in your vendors (which might confuse the IDE due to double class definitions)
Proposal
My proposal is to actually move the implementation of ICU polyfills to symfony/polyfill-intl-icu directly (the only change needed would be the namespace used for internal classes), and then change the order of the dependency. symfony/polyfill-intl-icu would be standalone, and symfony/intl would require symfony/polyfill-intl-icu (with the new version containing the polyfill as lowest bound).
This would give clear responsibilities to both packages, one providing the polyfill and the other one providing extra features.
The only impact would be on projects requiring symfony/polyfill-intl-icu and actually using the symfony/intl APIs without noticing they don't define a requirement for them, as symfony/intl might not be installed anymore. But the symfony/polyfill-intl-icu package does not document that these APIs become available due to the implementation details.