Closed rkrahnen closed 1 month ago
Using provide
does not have the same benefit for us as a root package. Those polyfills will still be installed. But there is very little harm in having them installed, so I have no objection to removing them if it makes things easier for users who use composer/satis
as a library (require
) for their own project.
First of all, thank you very much!
Are you sure that provide
does not have the same benefit for you? I just installed the project with composer create-project --keep-vcs --no-dev composer/satis:dev-main
and the polyfills were installed because you removed the replace
block. I then added the block again, but with provide
and a composer update --no-dev
removes the polyfills.
Looking at the distinction between them (provide
vs replace
), I guess that should work too. But since we do not actually enforce a minimum php
version requirement (and I would prefer to avoid that to allow more flexibility for those using composer/satis
as a library), it might actually be safer to just not list them.
I agree with not enforcing a minimum php
version. 👍
Thanks for the quick reply!
I agree with not enforcing a minimum
php
version. 👍
I misspoke. In a way we do enforce it because the constraints of our dependencies are bumped occasionally. See https://github.com/composer/satis/commit/2df25498b62080d0ab088347e2b63f671056eae8 for reference.
Describe the bug I have the problem that the "replace" for polyfills leads to an uninstallable set of packages because another package also uses "replace" for the same polyfills.
To Reproduce Use the following
composer.json
and runcomposer update
.Outcome
Expected behavior If I understand the Composer documentation correctly, several packages can deliver the same "provide", whereas a "replace" can only deliver one package. To avoid conflicts with other packages, I would suggest replacing "replace" with "provide".
Additional context I know that in my example the requested change would still lead to an uninstallable set of packages due to conflicting version constraints for symfony/console, but that is another topic. :-)