Feature #35415

Unified plugin api esp. regarding patches

Added by Ludwig Meysel 4 months ago.

Status:NewStart date:
Priority:NormalDue date:
Assignee:-% Done:


Category:Plugin API
Target version:-


Many plugins use different ways to include own lib-code. A common topic I came across is applying patches and consuming hooks. Sometimes the files are require'd having something like

unless FoobarController.included_modules.include? MyPlugin::Patches::FooControllerPatch
  FooController.send(:include, MyPlugin::Patches::FooControllerPatch)

in the bottom.

Sometimes the require is wrapped in Reloader's to_prepare-callback (which seems quite useless to me), other plugins have some kind of apply_patch-method implemented, which does the same as the code above in a more generic manner (IMO the most elegant way to go).

While all these techniques basically work, it often invites to mess up with the auto reloader. When doing some tweaks in the codebase (or even develop my own plugin), I either have to disable foreign plugins or painfully restart the dev-server with every change, when autoloading is not properly implemented. Otherwise I face the often reported problem of "Cannot autoload Constant ..."-Error.

My suggestion is to provide a more unified API for applying patches and consuming hooks.

I could imagine a simple approach e.g. of an appyl_patch function, which forwards the params to an array, which then is processed internally by the ActiveSupport::Reloader.to_prepare callback.

Another (more opinionated) approach is to grab all patches from plugins/.../lib/patches/*.rb, after a plugin was registered, which also was applicable to the hooks.

Anyways, I think there should be some mechanism to provide plugins safely, which do not mess up with the autoloader. This could also catch compatibility-stuff I have also often seen like Rails.version < '5.1' ? ActionDispatch::Callbacks : ActiveSupport::Reloader.to_prepare.

Also available in: Atom PDF