"pre-package-uninstall" script fails with service providers of non-installed packages

[halloei]

Laravel Version

12.36.1

PHP Version

8.3.27

Database Driver & Version

No response

Description

The pre-package-uninstall Composer event triggers Illuminate\Foundation\ComposerScripts::prePackageUninstall which boots the application. The boot fails if a service provider (in app/Providers/) is extending a service provider of a package which is not installed at the moment.

The error message:

Installing dependencies from lock file (including require-dev)
Verifying lock file contents can be installed on current platform.
Package operations: 33 installs, 0 updates, 2 removals
> Illuminate\Foundation\ComposerScripts::prePackageUninstall

In AdminPanelProvider.php line 22:

[Error]
Class "Filament\PanelProvider" not found

Exception trace:
[...]

Steps To Reproduce

1. Create branch-a from main and switch to it
2. Add a Composer package that includes a service provider you should extend within your app:

   composer require filament/filament:"^4.0"
   php artisan filament:install --panels

   (This creates app/Providers/Filament/AdminPanelProvider.php which extends \Filament\PanelProvider and adds it to bootstrap/providers.php.)
3. Create branch-b from main and switch to it
4. Install any Composer package (e.g. composer r --dev barryvdh/laravel-debugbar)
5. Switch to branch-a and run composer install

[cosmastech]

I'll try to take a look at this this weekend. Does laravel-debugbar not get installed in that scenario?

[halloei]

Thanks. It gets installed in step 4, but it should be removed in step 5 which fails.

[github-actions]

Thank you for reporting this issue!

As Laravel is an open source project, we rely on the community to help us diagnose and fix issues as it is not possible to research and fix every issue reported to us via GitHub.

If possible, please make a pull request fixing the issue you have described, along with corresponding tests. All pull requests are promptly reviewed by the Laravel team.

Thank you!

[ferrl]

This happens because composer seems to prioritize package uninstall over other operations (install and update). If we could bind the script to some other composer event that happens after all package installation — this could probably fix the issue — but these events do not include uninstalled package information.

Personally, I'm not sure I agree this should be handled by the framework or the package.