Ancestors

Toot

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

Descendants

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

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

Written by Alessandro Lai on 2025-01-20 at 06:44

@shudder this is not just an issue with polyfills, but with any dev package. You could inadvertently use a class or a function defined in a package that is only in your dev dependency tree, and be none the wiser.

You can avoid these issues using checkers like this one: https://github.com/shipmonk-rnd/composer-dependency-analyser

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

Written by Marco "Ocramius" Pivetta on 2025-01-20 at 06:57

@shudder it is very much f'd up.

Including polyfills in a library is a big no-no.

=> More informations about this toot | More toots from ocramius@mastodon.social

Written by Chris Abbey on 2025-01-20 at 20:29

@ocramius @shudder I would expect cs-fixer is a tool though, not a library. Composer really should have a different autoload for tools wired into vendor/bin/ than it does for the main codebase. That way if a given tool needs a polyfill it can have it without forcing everyone to have it.

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

Written by Marco "Ocramius" Pivetta on 2025-01-20 at 20:56

@cabbey @shudder just add the dependency 🤷‍♀️

It is up to downstream to decide to polyfill, at the very edge.

As for tool installation:

mkdir -p "tools/$tool"
cd "tools/$tool"
echo "{}" > composer.json
composer require "$tool"
git add composer.lock composer.json

That's it, if you don't share address space with it. You could bring it further via nix flakes.

=> More informations about this toot | More toots from ocramius@mastodon.social

Written by shudder :verified: on 2025-01-20 at 21:33

@ocramius @cabbey Yeah. The assumption that Composer's require-dev is for dev tools might be wrong and I've seen it occasionally brought up for a couple of years now.

I liked the idea of an easy, integral dev setup though, and remaining use cases for dev dependencies seem to be very limited; almost non existent.

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