php and laravel have seriously changed my life. there was a time when i was so unsure of myself, thinking landing a job was just luck. but getting into the laravel community gave me confidence i didn’t even know i had, and now i’m giving talks, making full projects, it’s crazy
dude, if you’re reading this, just believe in yourself and work hard - you can do it
Most of the PHP packages out there are using this kind of php version constraint: "^8.3" (and using 8.3 in the CI). Am I the only one who thinks that this is wrong? Shouldn't it be "8.3.*"? Otherwise it would mean that you can install/use it with 8.4 as well (although we don't know if it is compatible with 8.4).
As long my package is not adapted to 8.4 or doesn't use 8.4 in the CI pipeline I wouldn't want users to use my package with 8.4 as I simply can not guarantee that it will work ...
•
my posting initially intended to highlight that packages are not automtically compatible with new minor versions and as maintainer you should take care of that fact.
when talking about breaking changes often TypeErrors are now thrown where before it silently accepted those.
but here are some real examples:
PHP 8.2 introduced stricter error handling in fread() and fwrite(), where passing invalid arguments now throws a TypeError instead of returning false.
PHP 8.2 made compact() stricter, throwing a TypeError if any key passed is not a string. Previously, passing non-string values would result in warnings but still execute.
Some mbstring functions received stricter type checks in PHP 8.2. For example, if mb_strlen() receives an invalid argument, it now throws a TypeError instead of returning false or producing a warning.
In PHP 8.1, the default fetch mode for PDO was changed from PDO::FETCH_BOTH to PDO::FETCH_ASSOC.
•
and the real life issues i had are not breaking but flooded my bug reporting tool: deprecation warnings. so i'd argue that you get rid of those immediately (this would be an argument to not use ^8.something). depending on error level settings they might even break your application 🙈
Maybe you've struggled with debugging GitHub Actions in the past, like me. Here are two things I do in every pipeline that make them just a little bit easier to troubleshoot.
masteringlaravel.io/daily/2024-10-28-make-it-easier-to-debug-github-actions
For anyone having some difficulty integrating Chartist in Laravel, i made a small tutorial. Hope it is of use!
peperkamp.dev/article/implement-the-chartist-library-in-laravel
Is there any useful way to mitigate security risk on db inserts based on hard coded strings in <script> tags?
Or is this whole plan silly