Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Problem/Motivation
To run on PHP 8, we need to bump, among other things, the version of:
- symfony https://github.com/symfony/symfony/issues/36872#issuecomment-653233968
- composer https://github.com/composer/composer/pull/8921
- twig
Also we should update our dependencies prior to 9.1.0.
Proposed resolution
Run COMPOSER_ROOT_VERSION=9.1.x-dev composer update
Remaining tasks
User interface changes
N/a
API changes
N/a
Data model changes
N/a
Release notes snippet
Dependencies are updated to latest version. See ...generate lock diff at time of 9.1.0.
Comment | File | Size | Author |
---|---|---|---|
#35 | 3157296-34.patch | 86.02 KB | jungle |
#35 | interdiff-20-34.txt | 296 bytes | jungle |
Comments
Comment #2
andypostComment #3
andypostI think it makes sense to wait 3-4 days for php8 alpha 2 and few more releases (maybe composer will got new release as well)
Comment #4
alexpott@andypost I'm not sure it matters tbh.
Comment #5
andypostfew more upgrades
- php8 support https://github.com/phpspec/prophecy/releases
- https://github.com/laminas/laminas-diactoros/releases/tag/2.3.1 (bugfix)
- https://github.com/Seldaek/phar-utils/releases/tag/1.1.1
Comment #6
andypostNow upgrades to
webmozart/assert
fix php8 https://github.com/webmozart/assert/blob/1.9.1/CHANGELOG.md#191Comment #7
andypostNew one
theseer/tokenizer | 1.1.3 | 1.2.0
Comment #8
andypostComment #9
andypostOne more upgrade
phpdocumentor/reflection-docblock | 5.1.0 | 5.2.0
Comment #10
andypostvalid patch
Comment #11
jungleNew releases from Symfony.
Comment #12
andypost@jungle it's interesting that your changes does not list symfony polifils which get update and listed in my previous patch... Any idea why?
On my side I wondered why
symfony/polyfill-php70
is added as we require 7.3 as minimal versionComment #13
jungleFYI. @andypost.
Comment #14
andypostA bit more updates, btw SF 4.4.11 added support for PHP 8 union types and a lot of bugfixes
Comment #15
andypostThe
symfony/mime
is the cause of new packagesComment #16
andypostI did split separate issue #3163133: Upgrade composer/composer and phpspec/prophecy dependencies to support PHP 8.0 because exactly this this dependencies mentioned in IS (fixed issues) #3109885: [meta] Ensure compatibility of Drupal 9 with PHP 8.0 (as it evolves)
Comment #17
andypostAnother php 8 compatible update released https://github.com/squizlabs/PHP_CodeSniffer/releases/tag/3.5.6
Comment #18
longwaveReroll following #3157434: Deprecate \Drupal\Tests\Traits\ExpectDeprecationTrait in favour of \Symfony\Bridge\PhpUnit\ExpectDeprecationTrait with some further minor version bumps:
Comment #20
longwaveReroll with some updates: Symfony 4.4.12 and 5.1.4 and a few minor version bumps elsewhere.
Comment #21
andypostLooks great 👍
Comment #22
catchThese polyfills are all getting added, which seems unnecessary?
Comment #23
andypost@catch as #15 points - this packages are new dependencies of
symfony/mime
Comment #24
longwaveYeah, quite annoying that we are adding back the dummy
paragonie/random_compat
after we removed it in D9, but nothing that we can do as far as I can see.Comment #25
longwaveActually, as we know we don't need
paragonie/random_compat
norsymfony/polyfill-php70
due to minimum PHP requirements, we can add them to "replace" in composer.json and they will be ignored.We could even do this for the PHP 7.2 and 7.3 polyfills?
Or, do we add these to core/composer.json instead of the root one?
Comment #26
andypostSounds like great idea for follow-up to remove useless packages
Comment #27
longwaveSo should we commit #20 as that solves the original issue here and look at removing all unwanted polyfills in a followup?
Comment #28
catchFollow-up for the other packages sounds good to me.
Comment #29
andypostI think polifils could be removed in this issue to touch composer.json files less times (too affects less other patches)
Comment #30
andypostI think it's ok to skip this new packages here as @catch said, and some follow-up to get rid of php:72 at least (could use one of existing issues which reference this
Comment #31
catchNearly there... we now need to add 'paragonie' to the cspell dictionary.
/home/catch/www/drupal/composer.json:39:10 - Unknown word (paragonie)
Comment #32
longwaveOpened #3168514: Remove unnecessary polyfills from composer.lock as followup.
Why do we spellcheck composer.json anyway? The readme and description are human readable, but everything else is meant for machines.
Comment #33
jungleRe #32 People might make spelling mistakes in not only description, readme, but also in drupal-core-project-message, scripts etc. :)
Comment #34
jungleComment #35
jungleAdded paragonie into misc/cspell/dictionary.txt
Sorry for the noise in #34 -- An empty comment.
Comment #36
jungleTo committer, credit @mondrake here if possible for opening and working on #3168107: Bump composer.json symfony/phpunit-bridge constraint to ^5.1.4 if applicable, please. I think it's a won't fix. Thanks!
Comment #38
catchComment #39
mondrake#36 please consider #3168107: Bump composer.json symfony/phpunit-bridge constraint to ^5.1.4 as a separate issue. Here we're updating dependencies without changing the Composes constraints, there we are upping the constraint in order to ensure a minimum version. Different objectives.
Comment #40
jungleThe version of symfon/phpunit-bridge is locked in the composer.lock file. Checked the linked issue I still do not understand why we have to update it to ^5.1.4 in composer.json, sorry!
Comment #41
jungleAdding the linked issue mentioned in #40 #3162403: Upgrade symfony/phpunit-bridge to 5.1.6 to fix badly formed deprecation error message
Comment #42
andypostIt will be easier to reroll related issue after this one
Comment #43
mondrake#40 because the lock file we ship with is a default, and the one that
composer install
will take for the versions to be installed. But a constraint we want to impose on the codebase build has to be specified in composer.json. With this in, out there anybody could (potentially) runcomposer update symfony/phpunit-bridge --prefer-lowest
and get back to 5.1.3, which we explicitly do not want because of the bug. The 'explicit' directive to use 5.1.4 as a minimum you set in the composer.json.So - one thing is to update the lock file with the latest versions, one thing is to specify the minimum versions per package.
Lots of fun in hi/lo dependencies testing with finding correct minimum versions if you wish :), see for example #3104474: D9, PHP 7.2 vendor min Testing issue - DO NOT COMMIT.
Comment #45
catchCommitted e91ccdd and pushed to 9.1.x. Thanks!
Comment #46
jungle@mondrake, make sense, thanks for sharing!
Comment #47
xjm