Support for psr/log:^2.0 |
TLDR; Version: If not too much trouble, I am hoping that future releases of codeigniter4/framework will support psr/log composer package version 2.X or 3.X. Or if no additional headache, 1.X, 2.X or 3.X.
Longer Version: I work as a software architect at my company and am currently in charge of upgrading our large 15+ year old PHP monolith application. We are currently running PHP 8.0 and about to pull the trigger on updating to 8.1, with our 8.2 upgrade planned to release by Nov 2025. During my testing I quickly discovered that codeigniter 3 and php 8.2 will never play well together. So I started planning the migration to version 4, and unfortunately starting a new repo is not an option, as codeigniter driven stuff is only a portion of the entire monolith. I had a successful POC branch running both CI 3 (3.1.13) and CI 4 (v4.4.8) in the same project, toggling which framework to load based on the request uri. This will allow us to spend about a year porting features from CI 3 to CI 4. My current concern is that we are stuck on psr/log:^2.0 in my project for the next several months until I upgrade multiple other heavy packages in order to allow us to upgrade to 3.X. Codeigniter4/framework >= v4.5.0 requires psr/log:^3.0 in the composer.json file, and therefore does not support version 2.X. I really don't want to have to downgrade psr/log to version 1.X to use the v4.4.8 release (since it only supports psr/log:^1.0) and I'm not sure about how long the 4.4.X branch will be supported/updated moving forward, plus there are only 2 releases < v4.5.0 without security vulnerabilities. So what I am essentially asking is would it be possible to have codeigniter4/framework repo support psr/log 2.X AND 3.X (also if not too much trouble, 1.X to ease migration for your users from v4.4.8 to v4.5.X)? According to the changelog, the only difference between psr/log 2.X and 3.X was adding void return types to the traits and interfaces. Many vendors allow multiple versions for this package, with several allowing all 3 versions. Would be great if this change could make it either into future v4.5.X releases, or v4.6.X releases if too late for v4.5.X. Mike
Unfortunately, I don't think it is possible. How could we do it?
Please send a PR to 4.6 branch if you can.
As you say, the difference between psr/log 2 and 3 is trivial.
If I were to do it, I would use the latest CI4.5 patched by myself for psr/log 2.0. The way to patch it is to fork CI4 and make my own package or use "composer patches" https://github.com/cweagans/composer-patches.
So normally how I would allow multiple versions would be to run all of my automated tests against each release I intend to support, then all that pass can be added to composer.json. So if all 3 psr/log versions pass, then I would create my feature branch against 4.6 branch, then run: composer require psr/log:"^1.0|^2.0|^3.0"
How composer reacts to that would be if the package already exists in composer.lock, it would just keep that version. If not, it would grab the newest version possible out of your defined choices. In other codebases where codeigniter4/framework is required by composer, it would act in the same way. If in composer.lock already, keep that version, otherwise pull in the newest version possible (they may have other dependencies that only work with certain versions, as in my case). However, I just pulled down the codeigniter4/framework repo down locally to check it out and found something I didn't expect. It appears Codeigniter4 actually overrides psr/log with it's own copy located in system/ThirdParty/PSR/Log via the AutoloadConfig class (system/Config/AutoloadConfig.php). It appears to be a copy of psr/log 3.0 in v4.5.0, and psr/log 1.X in v4.4.8, which makes sense, based off the requirement in composer.json. Based on the comments, it looks like this was done for a slight autoloading performance enhancement for these frequently used classes. So technically it could work by changing composer.json to allow psr/log 2X or 3.X, but any users who extend codeigniter core classes or change the logger used in any other way would have to ensure the replacement is compliant with the psr/log 3.0 interfaces/traits..... Which would be confusing if the composer.json file said ^2.0|^3.0. The only way to resolve that would be to remove the AutoloadConfig code and let composer natively autoload either version 2.X or 3.X, and I'm not going to ask your or anyone to do that. I assume they were put there for a reason in 2022 because it improved performance. I will take your suggestion and fork the repo so we can get started on the codeigniter 4 migration before our psr/log upgrade is completed. Once our psr/log upgrade is complete, we can switch back to the official repo for CI 4 and drop our fork. Thanks, Mike (07-17-2024, 10:55 AM)mteall Wrote: However, I just pulled down the codeigniter4/framework repo down locally to check it out and found something I didn't expect. It appears Codeigniter4 actually overrides psr/log with it's own copy located in system/ThirdParty/PSR/Log via the AutoloadConfig class (system/Config/AutoloadConfig.php). It appears to be a copy of psr/log 3.0 in v4.5.0, and psr/log 1.X in v4.4.8, which makes sense, based off the requirement in composer.json. Based on the comments, it looks like this was done for a slight autoloading performance enhancement for these frequently used classes. Slightly different. "system/ThirdParty/PSR/Log" is used only when Composer is not used. Remember CodeIgniter4 still supports Zip installations, and it depends on psr/log. So we need the copy for Zip installations.
That makes sense. I can't imagine managing a php app without composer these days, but everyone's situation is unique. I am in the process of forking the repo as we speak, thank you for your help.
Mike |
Welcome Guest, Not a member yet? Register Sign In |