Ancestors

Written by shudder :verified: on 2025-01-20 at 03:19

Cs-Fixer uses #php Symfony function polyfills that are automatically loaded by composer even if I don't call the tool itself.

That means I can't rely on php version compatibilty checks unless I uninstall all packages that depend on this feature.

Does it also mean that code from some deeply nested dependency might be indirectly executed anytime I run some dev tool from the same vendor directory?

I don't feel like I'm being paranoid thinking that this would be kinda fucked up.

=> More informations about this toot | More toots from shudder@phpc.social

Toot

Written by Larry Garfield on 2025-01-20 at 03:46

@shudder Not sure I follow the second question.

What kind of version checks are you doing? If you're doing function_exists(), it should be for the purpose of calling that function, only. In that case, the polyfill is doing it's job. If it's anything other than that or class_exists(), you should just use version_compare and not try to do feature detection.

Feature detection makes sense in JS where different implementations have a different random set of features. Not in PHP.

=> More informations about this toot | More toots from Crell@phpc.social

Descendants

Written by shudder :verified: on 2025-01-20 at 04:42

@Crell If my package is supposed to work on php 7.4 and I accidentaly use 8.x function there I'd expect failing tests when running it on php 7.4. Instead polyfill pulled and loaded (seriously WTF?) from dev tool makes it work and silences IDE errors.

Of course prod version won't work, because dev dependencies won't be pulled.

=> More informations about this toot | More toots from shudder@phpc.social

Written by Larry Garfield on 2025-01-20 at 04:45

@shudder Ahhh... I see now. And... yeah, I think you're right.

If you set the platform property of your composer.json to 7.4, that may tell the IDE to complain appropriately? Worth trying.

=> More informations about this toot | More toots from Crell@phpc.social

Written by Arthur Schiwon 🌍 on 2025-01-20 at 05:32

@shudder @Crell i'd argue that a code style checker does not necessarily have to fail there. A static analyzer, like phpstan, however should. Nevertheless, specifying the PHP requirement in the composer.json is a good idea.

=> More informations about this toot | More toots from blizzz@layer8.space

Written by shudder :verified: on 2025-01-20 at 05:43

@blizzz @Crell Everything should fail on undefined funciton except the package that actually uses polyfill with that function (Cs-Fixer in this case), but composer allows any package from vendor directory to inject itself into every composer autoload.

It's not a matter of php/platform requirement, but autoload:file implementation.

=> More informations about this toot | More toots from shudder@phpc.social

Written by Larry Garfield on 2025-01-20 at 05:45

@shudder @blizzz Well, more a matter of how PHP works. There is one single global table of available symbols (functions/classes/etc.). Once any symbol is declared, it's declared. Whether it's declared in the stdlib, an extension, the current file, or a require()ed file (which is what autoloading does), it's all the same. There's no concept of "imports" like in JS or Python.

Changing that at this point is essentially impossible without breaking a billion lines of code.

=> More informations about this toot | More toots from Crell@phpc.social

Written by Arthur Schiwon 🌍 on 2025-01-20 at 05:52

@Crell @shudder Right. Just got up, sorry 😅

=> More informations about this toot | More toots from blizzz@layer8.space

Written by shudder :verified: on 2025-01-20 at 06:06

@Crell When you autoload a file through class reference you assume that only this specific file will be included, not some code in a nested dependency of a package that wasn't even called. It's not a php issue, but composer's.

=> More informations about this toot | More toots from shudder@phpc.social

Written by Larry Garfield on 2025-01-20 at 06:35

@shudder hm, check the files block of the polyfill's composer.json. I'll bet it's listed there.

PHP doesn't autoload functions (long standing issue), so it's common for files with functions to get listed to auto-include when composer starts. It's the only opportunity for it to do so.

=> More informations about this toot | More toots from Crell@phpc.social

Written by shudder :verified: on 2025-01-20 at 06:56

@Crell Of course it's listed there. How would I otherwise know it's composer's autoload:file issue?

It's NOT the only opportunity to do so, but it's implemented this way. "Global" and "self" auto-include shouldn't be a thing - it should be tied to the package that depends on it and it's classes/namespace autoload.

=> More informations about this toot | More toots from shudder@phpc.social

Written by Larry Garfield on 2025-01-20 at 07:02

@shudder There is no such thing in PHP as a package. That's a concept invented entirely by Composer. There is no scope of package. Namespaces are just name abbreviations.

=> More informations about this toot | More toots from Crell@phpc.social

Written by shudder :verified: on 2025-01-20 at 07:09

@Crell What "packages" do you think I'm talking about this whole time?

=> More informations about this toot | More toots from shudder@phpc.social