Closed BigMichi1 closed 11 months ago
when i run composer out
after i merged the pull request the output is the following
root@i7-4770 ~/test-symfony # composer out
Do not run Composer as root/super user! See https://getcomposer.org/root for details
symfony/browser-kit v4.2.5 v4.2.7 Symfony BrowserKit Component
symfony/css-selector v4.2.5 v4.2.7 Symfony CssSelector Component
symfony/debug-bundle v4.2.5 v4.2.7 Symfony DebugBundle
symfony/doctrine-bridge v4.2.5 v4.2.7 Symfony Doctrine Bridge
symfony/dom-crawler v4.2.5 v4.2.7 Symfony DomCrawler Component
symfony/monolog-bridge v4.2.5 v4.2.7 Symfony Monolog Bridge
symfony/phpunit-bridge v4.2.5 v4.2.7 Symfony PHPUnit Bridge
symfony/property-info v4.2.5 v4.2.7 Symfony Property Info Component
symfony/serializer v4.2.5 v4.2.7 Symfony Serializer Component
symfony/stopwatch v4.2.5 v4.2.7 Symfony Stopwatch Component
symfony/templating v4.2.5 v4.2.7 Symfony Templating Component
symfony/var-dumper v4.2.5 v4.2.7 Symfony mechanism for exploring and dumping PHP variables
symfony/web-profiler-bundle v4.2.5 v4.2.7 Symfony WebProfilerBundle
The ones you say are not updated are indirect dependencies?
If you wanted to manually update all symfony packages from 4.2.5 to 4.2.7 - and not update any non-symfony packages - which commands would you run to do it?
as an example symfony/phpunit-bridge v4.2.5 v4.2.7
this package is a transitive dependency of "symfony/test-pack": "1.0.5"
which hasn't been updated, but mixing versions might break symfony, looks like it is not so easy achievable without running a global composer update which might than also bring in outher dependecy updates from transitive dependencies
@BigMichi1 I think you and I are thinking along the same lines now. I agree that you should ideally have all symfony packages on the same version in a project, and in fact maybe in some cases you "must" have them all on the same. But when they're deeply nested packages inside the lock file, I'm not sure how you'd achieve this - whether as a bot or as a human. If you update every dependency in the lock file then you might end up changing 10x more versions than just symfony.
Longer term the solution is that Renovate would have the capability to update nested dependencies in lock files, but by default have that functionality would be disabled because it would be too noisy otherwise. Then in cases like this you could have the capability to turn nested updates on just for symfony packages.
The issue occurs when Symfony does a major or minor version upgrade. Renovate correctly updates the require and require-dev sections, but there is another part in composer.json that also needs to be changed because it restricts the maximum allowed version of the symfony/* packages:
"extra": {
"symfony": {
"allow-contrib": false,
// This should match the version of Symfony packages in the require/require-dev sections
"require": "5.1.*" // <---
}
}
These links explain in more detail:
@msheakoski good find, thanks. I'm confused though because the docs for this extra
field do not include any mention of the meaning of "require": https://getcomposer.org/doc/04-schema.md#extra
I was trying to work out if this extra field is used by other packages or just symfony ones.
If we are trying to solve symfony alone, would it work if we treat extra.symfony.requires
as if it represents the package symfony/symfony
?
@rarkins The symfony/flex package registers a composer plugin which uses the configuration in composer.json's extra.symfony.*
section.
I'm not an expert in this domain, but I believe that the version in extra.symfony.require
is the source of truth for the constraints of symfony/*
packages.
The question is how to determine what the latest major/minor/patch version of Symfony is. Because symfony/*
packages do not all have their versions in sync with each other, there has to be another way. As you suggested, symfony/symfony
might be the best package to monitor. Perhaps @fabpot or @nicolas-grekas can offer some advice on this.
extra.symfony.require
applies only to packages that are listed in the replace
section of symfony/symfony
.
symfony/phpunit-bridge
is not one of them, neither is e.g symfony/monolog-bundle
.
@nicolas-grekas Interesting, I always wondered how that worked!
@rarkins I think that it would be safe to treat extra.symfony.require
the same way that you would treat symfony/symfony
. This change should fix the issue of keeping Symfony dependencies up to date.
Packages like symfony/monolog-bundle
, which are not affected by extra.symfony.require
, look like they can be updated the usual way without any issues, so nothing special needs to be done, just the usual require/require-dev version bumping.
Thanks @msheakoski @nicolas-grekas.
Yes, it seems like we can use symfony/symfony
as the package to determine the value in extra.symfony.require
.
The next question I have is whether we need to modify Renovate's default installation of composer
. e.g. do we need to install the Symfony Flex plugin so that the composer.lock
is updated correctly?
https://github.com/renovatebot/docker-buildpack/blob/master/src/php/build/composer.sh
@rarkins It should work without any changes to the buildpack. If extra.symfony.require
is present, it can be assumed that symfony/flex
is already listed in the require
section of composer.json
and everything will update accordingly.
Great. Last remaining step: can someone create a simple public repo that reproduces the current Renovate not working correctly?
@rarkins See https://github.com/msheakoski/issue-3558-symfony
It should want to update from 5.0.9 -> 5.1.0.
@msheakoski thanks. I need your help understanding what the desired behavior is. For example the first PR raised is this one:
Renovate's default behavior is to "pin" dependencies for applications so that's what you're seeing. Should it be pinning extras.symfony.require
as well? Or you prefer to not pin dependencies at all in this case, etc?
@rarkins Yes, I believe that extras.symfony.require
should be pinned to whatever version that symfony/symfony
would be pinned as.
Hi there,
Get your issue fixed faster by creating a minimal reproduction. This means a repository dedicated to reproducing this issue with the minimal dependencies and config possible.
Before we start working on your issue we need to know exactly what's causing the current behavior. A minimal reproduction helps us with this.
To get started, please read our guide on creating a minimal reproduction.
We may close the issue if you, or someone else, haven't created a minimal reproduction within two weeks. If you need more time, or are stuck, please ask for help or more time in a comment.
Good luck,
The Renovate team
What Renovate type are you using? Renovate CLI
Describe the bug i have a php/composer project which is based on the symfony skeleton. in my composer.json i have currently this
when i now run renovate it results in a merge request (want's to update 4.2.5 to 4.2.7) for only the specified symfony packages from
composer.json
. so the update in thecomposer.lock
file still contains other symfony packages with the old version. also the version in the extra section is not updated to the new one.Did you see anything helpful in debug logs?
To Reproduce
Expected behavior
composer.json
composer.lock
Screenshots none available
Additional context currently i'm using renovate in version 16.0.4