Closed
Description
Hi all,
since this code changes php-enqueue/enqueue@370b303
a trailing comma was added to constructor parameter. the composer.json says that the current version is compatible with php 7.4 but this feature was added in php 8.0. so on 7.4 systems the newest version is installed and breaks the system.
could you revert the trailing commas please?
Metadata
Metadata
Assignees
Labels
No labels
Activity
makasim commentedon Apr 18, 2025
I'd rather remove php7.4 from the composer. According to https://www.php.net/supported-versions 7.4 reached EOL like 3 years ago.
BlackScorp commentedon Apr 19, 2025
@makasim yeah i agree, but right now i have a legacy shopware 6.4 project which require this package and with 7.4 it installes a newer version which then breaks the shop. either the comma have to be removed or requirements have to updated ;)
makasim commentedon Apr 19, 2025
Pin the enqueue version that still works with 7.4.
scruwi commentedon Apr 24, 2025
Much better to follow semantic versioning and avoid breaking changes in patch releases.
makasim commentedon Apr 24, 2025
@scruwi Well, acording to semver
There is no any violation since enqueue is pre 1. You are not supposed to expect any backward compatibility between versions at all, but it is mostly preserved.
scruwi commentedon Apr 24, 2025
The issue isn't just the trailing comma — they ran a CS fixer that modified 436 files, broke compatibility with PHP 7.4, and tagged it as a patch release. And that would’ve been fine — but then they should’ve updated the composer.json to reflect that 7.4 is no longer supported. Yet that version is still listed there.
a8b3dd9
makasim commentedon Apr 24, 2025
Yeah, it was an oversight not to remove 7.4 support earlier.
Just a reminder that this is a community effort, and everyone here is contributing their time and expertise for free. If anyone notices issues or has a fix, they’re more than welcome to contribute.
scruwi commentedon Apr 24, 2025
Thanks for the update — and totally understand that things are still evolving while the library is in 0.x.
That said, I wanted to point out that the latest release introduces breaking changes (e.g. dropped PHP 7.4 support and massive CS fixer changes across 400+ files), but it's still tagged as a minor (0.x.y) version. While that's technically allowed under SemVer (since major version is 0), it's often unexpected for consumers who rely on ^0.x constraints and assume at least some level of stability within a given 0.x line.
If this release is meant to drop PHP 7.4, it might be worth updating composer.json to reflect the minimum supported version — otherwise tools like Composer won’t prevent installs on unsupported platforms.
JimTools commentedon Apr 27, 2025
Hi all,
Sorry to have caused the pain and misery with what should have been a simple task.
I've created a PR #1383 to update each composer.json to 8.1 based on the current supported versions of PHP and a previous issue #1340
I'd just like to say open-source maintainers have a thankless job working on projects in their spare time because they love programming, not because they have to. So share some love with them when you get the chance.
As a call to action, you are not powerless if you spot an issue in any OSS project; you can fix it for yourself, and if you push that upstream, it's likely to benefit many others who face the same problem.
makasim commentedon Apr 27, 2025
@JimTools thank you for your work!
JimTools commentedon Apr 27, 2025
Not a problem, still working on the CI failures, but it could be some time.
1 remaining item