-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Symfony 4.4.27 upgrade falls over on PHP 7.4 when calling str_contains #42280
Comments
I just saw this issue because I experience the same error, but in a different version; For me, this happens after updating from 5.3.x to 5.3.4 on php7.4. The error is thrown in the Dotenv class, though;
Composer version 2.0.8 2020-12-03 17:20:38 |
@crmpicco What version of Composer are you using? |
For me the same happens using
|
Looks like the Polyfills are not loaded for post-update commands then. That's a pity. |
Same thing: Fatal error: Uncaught Error: Call to undefined function Symfony\Component\Yaml\str_contains() in /var/www/site/vendor/symfony/symfony/src/Symfony/Component/Yaml/Parser.php:214 Trying to upgrade Symfony v4.4.25 => v4.4.28 |
|
I am affected by this too, but not on all systems (with the same source). I upgraded from local dev (working)
remote dev (not working)
I tested both php EDIT: I pinned 5.3.0 for now, that version continues to work as expected |
Is this a new thing? Wouldn't they be available project-wide? |
Same here. Also, not only |
I'd be great to understand why this happens. This is strange to me. |
Just as an idea: could it be that the polyfill file is read before updating (through any include stuff), and not a second time after updating, as it already got included through any of the ways Composer's autoloader could include it? |
It's not only happening for post-update commands. I have some commands defined by If I explicitly call |
Reproducer: https://github.com/derrabus/yaml-reproducer
|
I think this is a bug in Composer, it doesn't load the |
The reason is pretty straightforward. There is a difference between runtime code (code that execute after inclusion of the vendor/autoload.php file) and build time code (code that is executed when composer builds all its files). Build time code is typically provided by Composer plugins. For this code to work (classes to be autoloaded), Composer registers a temporary PHP autoloader, which works similar to the one that is registered when including the vendor/autoload.php file, with the exception that "include files" are not included. As I outlined in the Composer issue tracker, I don't think there is much that can be done on Composer side. I see two possible solutions:
For me this also shows that using polyfills (or any globally defined function) has its limitations and should not be introduced lightly (at least not in a bugfix version, as maintainer of other libraries can not define dependencies reliably any more, when bugfix versions can break for bugfix releases) |
Of course I'm biased, but I don't see that the benefits such cleanups provide, justify issues introduced with requiring a PHP8 polyfill when using these libs with PHP versions < 8. At least it should be considered doing such cleanups later in a release cycle and for sure not for bugfix releases. As of now such changes mean:
|
Another side note: The underlying pain point here isn't a polyfill, breakage or performance impacts, but IMHO the growing usage of globally defined functions. Global functions are still odd in PHP, as they require to be defined upfront making code that depends these function depend on globally initialized state. Unless PHP intself finds a way to autoload functions in an acceptable way, my stance is to stay away from global functions as far as possible and use static methods instead. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Introduced with v5.3.4, v5.2.12, v4.4.27 |
@maikschneider @helhum Please don't turn this issue into a chat. Let's discuss how to solve the problem described here. |
Okay, since this is apparently the way Composer works, I suggest we revert the introduction of the Polyfill in Yaml and Dotenv at least. Are there any other components that we would expect to be used in composer plugins? |
This comment has been minimized.
This comment has been minimized.
If there are methods used which are only available in PHP 8, why is the composer dependency then saying I also consider this a breaking change and it should NOT be tagged as a bugfix release. |
Thank you for your input, @simonschaufi. You are more than welcome to test my pull request. |
This is also a problem with Symfony/DotEnv |
I am also facing same problem when using composer script from This is happening due to changes in e585b26 and also due to the fact that composer does not autoload files from To fix the problem, I am using fixed version of symfony as |
This PR was merged into the 4.4 branch. Discussion ---------- [Dotenv][Yaml] Remove PHP 8.0 polyfill | Q | A | ------------- | --- | Branch? | 4.4 | Bug fix? | yes | New feature? | no | Deprecations? | no | Tickets | Fix #42280 | License | MIT | Doc PR | N/A This is a partial revert of #41576 and #41973. Commits ------- 08ecbf5 Remove polyfills from Yaml and Dotenv
Same problem for me with symfony/expression-language, I am forced to downgarde to 5.1.11. Can you have a look? Thanks |
Well.. All components could be used at some point in somebody's plugin.
|
…lmann) This PR was submitted for the 5.3 branch but it was merged into the 4.4 branch instead. Discussion ---------- [ExpressionLanguage] [Lexer] Remove PHP 8.0 polyfill | Q | A | ------------- | --- | Branch | 5.3 | Bug fix | yes | New feature | no | Deprecations | no | Tickets | Fix #42280 | License | MIT | Doc PR | N/A This is a partial revert of #41576 and is a followup to #42296 Commits ------- d2f39e9 Remove polyfills from ExpressionLanguage
The newest versions of Symfony HTTP client use PHP 8 functions and require PHP 8 polyfill which does not work in context of Composer plugin. :( symfony/symfony#42280 composer/composer#10024
…s (xabbuh) This PR was merged into the 5.4 branch. Discussion ---------- [Yaml] revert using functions provided by polyfill packages | Q | A | ------------- | --- | Branch? | 5.4 | Bug fix? | yes | New feature? | no | Deprecations? | no | Tickets | Fix #43943 | License | MIT | Doc PR | This reverts #41431 for the same reason for which we merged #42296 (see #42280 and composer/composer#10024 for more information). Commits ------- 3b9b700 revert using functions provided by polyfill packages
Symfony version(s) affected: 4.4.27
Description
I have just upgraded from Symfony 4.4.26 to 4.4.27 and have hit my first upgrade issue in a long time.
I am running PHP 7.4.15 as i'm not ready for PHP 8 yet, however the Yaml
Parser.php
is looking for str_contains - which is only available in PHP 8.I was under the impression the polyfills existed for this reason, but they don't seem to be working this time.
How to reproduce
composer update
Additional context
I was under the impression the polyfills existed for this reason, but they don't seem to be working this time.
Bizarrely the app still boots up, but a composer update falls over as per output below:
The polyfills are all installed:
composer show | grep polyfill
Removing the following from my
composer.json
fixes it, but i'm not convinced I can safely remove that and leave it out:The text was updated successfully, but these errors were encountered: