Framework: [5.5] Cannot clear package auto-discovery cache

[aleksandrlat]

• Laravel Version: 5.5.3
• PHP Version: 7.1
• Database Driver & Version: Not relevant

Description:

If package providers cache becomes invalid it is impossible to clear it with clear-compiled command. But clear-compiled command looks right tool to use.

By invalid cache I mean bootstrap/cache/packages.php contains non-existing package service providers.
We commit all code from vendor folder to git. There are reasons for this.
When we switch branches some dependencies can disappear but cache still contains them.
This was not an issue before package discovery.
Also I can clean cache only manually deleting bootstrap/cache/packages.php.
clear-compiled fails because it loads non-existing service providers for some reason.

Steps To Reproduce:

• install auto-discoverable package for example laravel/passport
• delete this package manually from vendor folder
• open home page, error happens: laravel loads non-existing PassportServiceProvider

[Dylan-DPC]

Have you tried composer du?

[aleksandrlat]

It works thanks!

I think it works because of

"post-autoload-dump": [
    "Illuminate\\Foundation\\ComposerScripts::postAutoloadDump",
    "@php artisan package:discover"
]

in composer.json

But we don't have composer on production servers. And we need to clear cache there too. Is it possible to run ComposerScripts::postAutoloadDump without composer?

[Dylan-DPC]

But we don't have composer on production server

:scream: how do you install dependencies then? pushing the vendor folder?

You can close this issue though since this repo is for bug tracking. You can use the forums or the slack channel

[aleksandrlat]

Yes we push full vendor folder to git. There are reasons for this.

Should clear-compiled command work to delete bootstrap/cache/packages.php? I thought the purpose of this command is to delete cache from bootstrap/cache. But it fails in my particular case.
If clear-compiled should not work in this case I will close issue.

[Dylan-DPC]

You can run php artisan package:discover.

[aleksandrlat]

php artisan package:discover fails. Any artisan command fail because it loads not existing service provider.

That would be nice to add short comment explaining why issue is closed.

[aleksandrlat]

@themsaid could you please comment why this was closed?

[themsaid]

It's not a bug in the framework, you can use the forum for discussions or if you have a suggestion
please use the https://github.com/laravel/internals repo.

A composer dump-autoload after each deploy would solve your issue but it seems like you have a special installation method out of the norm, so I suggest you seek help on the forums.

[LastDragon-ru]

@themsaid, composer dump-autoload do no solve this problem - after running you still have nonexistent provider classes inside bootstrap/cache/config.php and all artisan commands will fail. Moreover, seems this bug can be fixed only by hands with rm bootstrap/cache/config.php :(

I think this should be reopened and fixed.

[giovannipds]

I agree with @LastDragon-ru, I went through same thing today, only rm bootstrap/cache/config.php solved the issue and has restored all commands.

Neither of these were working:

composer du
composer dump-auto
composer dump-autoload
composer install
composer update
composer remove old-package-name
php artisan cache:clear
php artisan config:clear
php artisan package:discover

All of them were showing Class 'XXX' not found.

How did I get there? I've installed a package (composer require package-name), didn't like it, went back on the version control, running git checkout -- . + rm created files, then tried all said above.

It'd be cool if php artisan cache:clear could solve that.

I think the issue should be re-opened.

[Christofu450]

Same here than @LastDragon-ru and @giovannipds
This needs a fix.

[travisbotello]

Same issue here. We are using Laravel Forge with quick-deploy on our staging environments and the deployment scripts fail in the described cases. The only fix is to manually ssh into the server and rm bootstrap/cache/config.php. Definitely needs a fix!

[andreshg112]

I don't know why package:discover has to connect to database. I cannot event cache:clear or config:cache.

[taai]

I ended up with writing Composer's pre-autoload-dump script in composer.json file:

{
    "scripts": {
        "pre-autoload-dump": [
            "@php -r \"array_map('unlink', glob('bootstrap/cache/*'));\""
        ],
        "post-autoload-dump": [
            "Illuminate\\Foundation\\ComposerScripts::postAutoloadDump",
            "@php artisan package:discover --ansi"
        ]
    }
}

[rs-sliske]

@andreshg112

either your app or a package it is using is trying to access database from a service provider / adding an event listener

personally i recently had this with telescope

[andreshg112]

@rs-sliske , yes. I think that was the problem. I had a called to Schema in AppServiceProvider.php.
I just used a try-catch in order to solve it.

[beerwin]

bootstrap/cache is causing other problems as well: I use Laravel Nova, and create custom tools/cards/fields for it for our projects.

When I add a new one, i always have to manually clear this folder just to get my components working. No cache clearing command in existence fixes this.

I believe, @taai' solution should be considered for inclusion.

[mpyw]

@andreshg112

The real solution is here: https://github.com/mpyw/laravel-cached-database-stickiness/commit/ba9749f6a280345880a0531fef123fc45ebe3501?short_path=04c6e90#diff-04c6e90faac2675aa89e2176d2eec7d8

[giovannipds]

@mpyw is that serious that it was caused by the Schema::defaultStringLength? lol I'd never imagined that.

[giovannipds]

If that's right, it'd be cool if Laravel News get updated: https://laravel-news.com/laravel-5-4-key-too-long-error since it's one of the first posts related to defaultStringLength.