Coming back from a very long hiatus, with some updates and future plans.
Posted on 27 October 2024 at 11:08:56AM.
Hi! It's been a while since I've been posting in this blog. A lot, lot, lot has changed since my last post. What has happened to me since then? I decided to take some time off from doing open-source projects since 2020 due to personal reasons. But around this year, I've managed to gain some momentum in my existing projects that I managed to update most of them to the latest version of PHP (which is 8.3 at the time of writing this post). As 2025 is fast approaching, I'm trying to create now my next year's resolutions below (sorry in advance but it might take long):
As I look back in my Github profile, all of my projects with the most stars are packages for Codeigniter 3 like Combustor and Refinery. But as I noticed, Codeigniter 3 is now not being updated officially by their caretakers and instead focuses more on its version 4. While it's all good, I decided to update all my packages related to Codeigniter 3 and managed to update them until the latest PHP version.
Why did I do this? Is it for nostalgia? Partially, yes. But the most concrete answer that I can give is that I want to hone my skills back when writing open-source code. It's pretty funny to me that Travis CI was dead for open source around 2020 and I haven't touched any continuous integration to all of my packages since my hiatus as they were previously connected to that service. So, I decided to learn Github Actions as its replacement and it’s been both challenging and fun to migrate all of it to a new workflow automation.
Additionally, I decided to learn more coding style and code documentation improvement through PHPStan and PHP Coding Standards Fixer (PHP-CS-Fixer). It has been so refreshing that it provided me with a quality-of-life improvement when writing code as it helps me to detect errors before even running the code and allows to style it according to my preferences. I also use the strictest level in PHPStan which is level 9, to encourage me to provide less errors when writing PHP applications. With this, I ditched my workflow in Scrutinizer CI (for now) to both PHPStan and PHP-CS-Fixer instead.
As I already updated all my packages related to Codeigniter 3, what comes into my mind next is if I proceed to Codeigniter 4. Honestly, I don't want to go there for now because when I looked at their documentation in a first glance, I don't like how they structure the processes in building one's first application in Codeigniter 4.
However, I am more inclined to re-write Codeigniter 3 from scratch based on the things I learned when writing Slytherin and Zapheus. Sounds ambitious, but I want existing users of the legacy Codeigniter projects to have a drop-in replacement of Codeigniter 3 and be able to migrate them to version 4 with minimal effort. Being a drop-in replacement also helps my packages based on Codeigniter 3 like Combustor and Refinery to be integrated easily to version 4 with little modifications (hopefully). With this, I will try to look the internals at Codeigniter 4 and will also try to incorporate those in this new endeavour. Hopefully this plan will also improve my understanding in writing frameworks.
For some reason, I still have some appreciation to write PHP packages and applications with version 5.3 as its minimum version. I know it’s somehow bad and we should be practicing in writing them to its latest version, but I like this preference as some tools like PHPStan helps me to detect errors regarding data types and force me to be descriptive when writing methods and variable names. With this, it makes me forget (for now) the native data types provided by version 7 which I previously liked in its first release.
As I want to still be writing PHP packages around version 5.3, there are some packages for sure that will be incompatible under it. The first thing that I can remember regarding incompatibility is the interfaces from PHP Standards Recommendations. Although I understand it was done to improve a one's package by forcing them to use version 7 or 8 as its minimum version (e.g., PSR-15) and to be safe from security vulnerabilities introduced in its previous versions, I wish they could release their new packages in version 1 starting from PHP 5.3 first then version 2 starting from PHP 7.0. In that way, maintainers can safely release their packages without constraints from multiple PHP versions. This was also based on my experience in incorporating PSR-15 in Slytherin as it is being forced to be in PHP 7.0 in which it breaks my philosophy in Slytherin that is to be used in any PHP version available.
With this, I have a plan to rewrite those PSR interfaces with its minimum version to 5.3 through Zapheus. This plan sounds stupid, which I am aware, however this allows me to create modern PHP applications using the said PSR interfaces regardless of PHP version. To start that plan, I will introduce backward compatibility breaks to Zapheus' internals as they are not compatible by default:
// Instead of "RequestInterface" ... -----------
use Zapheus\Http\Message\RequestInterface;
// ... it will be now "ServerRequestInterface".
use Zapheus\Http\Message\ServerRequestInterface;
// ---------------------------------------------
$app->pipe(function (ServerRequestInterface $request)
{
// ...
// Instead of "method" ... -----------
$method = $request->method();
// ... it will now become "getMethod".
$method = $request->getMethod();
// -----------------------------------
// ...
});
// ...This plan also allows me to pass the torch of being a PHP micro-framework from Slytherin to Zapheus, as this plan includes Zapheus being a drop-in replacement for Slytherin with minimal effort, like only swapping their namespaces. With Slytherin approaches to version 1.0, I want to stop it there and will now focus more on Zapheus.
Since I already started the migration of my PHP packages to the latest PHP version starting from the ones based on Codeigniter 3, I also want to extend this plan to my personal packages as well like Staticka and Transcribe. With this, I will introduce backward compatibility breaks to them initially as it is hard to migrate their codebase due to minimal to no documentation being provided in its basic usage and its internals. As I checked their code, I realized that they are also over engineered, which is a mistake that I needed to atone for when updating my packages in the future.
I already managed to start this plan in Blueprint and Describe, which are being used by the packages Combustor and Refinery. The documentation of the specified packages was also improved, giving the readers the whole documentation for each usage and allows me not to perform any breaking changes when writing code for their future updates.
For now, that's all my plans for 2025 regarding the open-source side. How about my personal side? It's still personal to be honest but to give at least one, I think one of the highlights of it is I created a habit of creating documentation or guide for all the tasks that I've been doing repeatedly, no matter how small it is. By writing it to a document, that knowledge becomes permanent, and it also helps my other colleagues to perform those tasks in my behalf if I was away or during vacation. This habit also applied to my PHP packages that were being updated.
I am hoping that the plans I listed above will come in fruition as I want to learn more in myself, hone my skillsets, and not being stagnant. Realizing these plans will also help me in the future as I provided an ecosystem of packages that I wrote that can be useful in a future project.