composer-patches VS Laravel

if you're using composer with joomla, and the plugin is installed via composer, you can commission someone to make the necessary changes, create a git diff patch that encapsulates the changes, then leverage cweagans/composer-patches to make it work. if/when new changes are necessary, they can build a new patch.

I've had problems with libraries using final having an API that isn't customizable enough in a particular way I need because I'm innovating in some way they could never have considered in the past, so my choice ends up either needing to fork the library or monkey patch it with https://github.com/cweagans/composer-patches so I can get rid of final so I can keep using it. They wouldn't accept a change in API or behaviour because it would break things for other users, etc.

There are cool tools to integrate patches from drupal.org (or your own custom patches) into your composer managed drupal website. For example (not drupal specific but works well with drupal+composer): https://github.com/cweagans/composer-patches

If the PR get's merged, I want `yay` or `pacman` to skip the patch. Ideally it would be declared in a pacman.patches file or similar to what https://github.com/cweagans/composer-patches provides for composer PHP package managment.

This has been an issue for a while, and is outlined here: - https://github.com/cweagans/composer-patches/issues/172#issuecomment-587147692 - https://github.com/cweagans/composer-patches/issues/326

Install a package that allows the composer to work with patches:

And if for some reason you do not want to make a fork, you can also create a composer patch with the help of https://github.com/cweagans/composer-patches

https://github.com/cweagans/composer-patches - this lets you patch packages when they are pulled in by Composer. I have used it in the past to get minor bugfixes into a project ASAP without having to wait for upstream or forking the entire package.

Hope this saves a future team from unexpected behavior resulting in (potential) production data loss.

When using Postgres, Laravel's default method for truncate uses the cascade option, which will ignore foreign key constraints and potentially wipe large amounts of data with no confirmation or warning.

It was originally introduced in 2018: https://github.com/laravel/framework/pull/26389/files

Here are two threads on it if you are curious: https://github.com/laravel/framework/issues/29506

I am just exploring middleware in this post, but as you can see this is quite a different approach than we've seen historically. I sat there scratching my head, "How do I set up my own middleware? How do I change the defaults?" I had to explore the Illuminate\Foundation\Configuration\Middleware class to find out.

For example check out this issue I reported on their side: https://github.com/laravel/framework/issues/49089

It does not mean you should absolutely use it everywhere, but it can make sense for your case. Many frameworks, like Laravel use it to compose new projects.

https://github.com/laravel/framework/blob/00894b89e42a9d707c...

Even Tinker is a few lines of code to extend PsySH and credit is barely given.

Taylor Otwell is a fiend for creating wrappers around solid open source libraries, using PHP magic and encouraging bad practices, all just to breed an ecosystem ultimately to land him a Lambo, fuelled by amazing open source foundations that have barely been contributed back to by him.

This same system has been used in Laravel since version 4.0* albeit in the more PHP plain way, using call_user_func_array (Laravel Model Class).