The commerceguys/intl v2 library now specifies parameter types and return types for methods.
Drupal Commerce is going to require the v2 (See #3345682: Require commerceguys/intl version 2).
Commerce itself is decorating the physical class, therefore we need to align with the changes in Physical too.
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | 3345698-2.patch | 5.55 KB | jsacksick |
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
compare
Comments
Comment #2
jsacksick commentedComment #3
jsacksick commentedCommitted!
Comment #6
berdirThis is a BC break, no, shouldn't this go into a new major release?
Also, without explicit dependency/conflict declarations between this, commerce and commerceguys/intl, it is possible to update to incompatible combinations of these packages. A project I updated somehow only updated physical and not commerce/intl, so I had the latest version of physical and commerceguys/intl 1.x, resulting in this very confusing error:
Fatal error: Declaration of CommerceGuys\Intl\Formatter\NumberFormatter::format($number, array $options = []) must be compatible with Drupal\physical\NumberFormatterInterface::format(string $number, array $options = []): string in vendor/commerceguys/intl/src/Formatter/NumberFormatter.php on line 68
(confusing because that physical interface is only implemented in the commerce subclass that isn't mentioned here)
Comment #8
luksakI have the same issue as described in #6. I would be nice to have a fix for this soon...
Comment #9
berdirThere won't be a fix. Either downgrade physical back to 1.2, which is OK as this is the only change in that release or upgrade commerce. The conflict should have been added to the 1.3 release, but nothing can be done about that now.
Comment #10
jsacksick commentedApologize for this, I thought about adding the conflict in Commerce, but forgot to do the same here.
Comment #11
giorgoskFor anyone still looking temp solution is