Introduce auto-registration for addons

[duncanmcclean]

This pull request implements statamic/ideas#88 and statamic/ideas#523. It introduces auto-registration for things in addon service providers.

Supported things

As long as the folder structure convention is followed, any things will be automatically registered.

• Actions (src/Actions)
• Tags (src/Tags)
• Scopes (src/Scopes)
• Fieldtypes (src/Fieldtypes)
• Modifiers (src/Modifiers)
• Widgets (src/Widgets)
• Form JS Drivers (src/Forms/JsDrivers)
• Routes (routes/web.php, routes/cp.php, routes/actions.php)
• Update Scripts (src/UpdateScripts)

Unsupported things

There are still a few bits & pieces which will need to be registered manually after this PR.

• Event listeners
• Event subscriptions
• Policies
• Commands
• Scheduled commands
• Stylesheets
• Scripts
• Middleware

[duncanmcclean]

I can't find any existing tests for the AddonServiceProvider so I've left out tests at the moment. I imagine they'll be a little more involved than setting up tests for other things.

[Christophvh]

Looks great, but are there some benchmarks run? Because checking all files on every request seems like a thing that would slow down large websites quite a bit?

[jonassiewertsen]

I like the idea a lot, but am concerned regarding the performance as well.

Wouldn't this be a perfect case for some similar approach like the "@php artisan package:discover --ansi" command, executed as composer post-autoload-dump?

This would mean to only read files if updating, installing etc. via composer., which then creates a caching file inside the bootstrap folder.

Loading the cached bootstrap file should be really fast and still add the suggested approach to auto register everything inside any addon.

[duncanmcclean]

Yes, those are fair points. Performance wasn't something I thought about when making the PR.

I'll make this PR a draft and see if I can do something similar to how Laravel handles it (with caching stuff in the bootstrap folder).

[jasonvarga]

I really don't want to add this precisely because of the constant file IO others have brought up.

I'm going to close this for now but feel free to reopen if you come up with something more performant.

Thanks for understanding.

[jesseleite]

Maybe when we build the Addon manifest file, a cache/manifest can also be created for all the files Duncan is auto-registering? Then it would only be happening once on install, not per-request.

[duncanmcclean]

Maybe when we build the Addon manifest file, a cache/manifest can also be created for all the files Duncan is auto-registering? Then it would only be happening once on install, not per-request.

Hmm, the only issue I can see with that is that what happens when you create a new tag/modifier/etc class without running the statamic:install command (I think that's the one)?

[jesseleite]

what happens when you create a new tag/modifier/etc class without running the statamic:install command

Well it's an addon, so any changes you make in an addon are going to need to be composer updated, so the addon manifest will get recreated.

Of course, this won't be the case if you've symlinked an addon into your app for development purposes, but then you could manually run php please addons:discover after adding a tag/modifier/etc. This would be something we'd have to document for addon devs who symlink in development, IMO.

Your thoughts, @jasonvarga?

[jasonvarga]

Well it's an addon, so any changes you make in an addon are going to need to be composer updated, so the addon manifest will get recreated.

During development of the addon it'll be a pain. You'll need to remember to run the command if you add a new thing. The effort in doing that is about the same as just adding a line to your service provider.