[12.x] Dispatch framework events on composer pre-package-uninstall event

[cosmastech]

Looking at this issue in the Telescope directory, Telescope is not cleaning up after itself during the uninstall process. While this can definitely be added to Telescope (and some kind of polyfill functionality WILL need to be added), it seems like something other packages might want to clean up after themselves with this functionality. Probably via the composer pre-package-uninstall hook.

Looked into this a bit further, and it seems like we'll need to add a ComposerScript::prePackageUninstall() method, and then some way for service providers to register their package clean up scripts. The pre-package-uninstall hook isn't fired for children, only the project root.

[taylorotwell]

I like the idea in general - do we need those other pieces before this feels useful on its own?

[cosmastech]

I like the idea in general - do we need those other pieces before this feels useful on its own?

The initial goal was just to close the linked telescope ticket, but this doesn't come close to solving that. (It has a long history of Laravel releases to consider 😅 )

I think in order for this to be useful, we need two things:

• a method in the service provider to register clean up code
• a ComposerScript method that boots the application and runs the matching service provider's code

The service provider feels a little heavyweight, but it seems like the place package maintainers would tend to put it. It also requires that they set the package name inside of the provider.

Another option is to allow devs to set a new extra value in their package's composer.json. Something like "on-uninstall" where they can list commands to run.

Before uninstalling, we would find the package being removed and run the commands listed under that key.

That second option feels a little bit cleaner, but I think the dev experience is a tad more confusing since it would require the devs to create console commands just for uninstalling. (They may expect that the application is booted, which it certainly could be but maybe it's better to avoid.)

Let me know your thoughts.

[cosmastech]

@taylorotwell opening this back up for review to get your feedback on it.

I was able to get the composer uninstall action to trigger a clean up for Telescope.

One thing that I can't figure out is why calling Artisan::call('telescope:uninstall') dies silently inside of an event listener. I was having a dickens of a time trying to figure out what the root cause was. That said, I was able to add something like this to the TelescopeServiceProvider@boot() method:

$this->app['events']->listen('composer_package.laravel/telescope:pre_uninstall', function ($event) {
    $this->app->make(UninstallAction::class)->handle();
});

I went with string naming for the events so that packages don't need to listen for an event class, but could be more specific. I don't really know if there's valuable data inside of the PackageEvent that would be relevant to devs.

edit: Another thought might be to create a Laravel composer plugin so that libs can hook into all events. I didn't search, maybe this already exists in the open-source world.