view:cache behaves differently when called by optimize command

[dwightwatson]

Laravel Version

11.0.7

PHP Version

8.3.3

Database Driver & Version

No response

Description

This is a little tricky, but I ran into this issue after upgrading to Laravel 11 and first suspected it was a problem with Blade Heroicons Kit.

In Laravel 11 the optimize command was extended to cache events and views.

When running optimize on a fresh app with the Heroicons kit it blew up:

➜  heroicons php artisan optimize

   INFO  Caching framework bootstrap, configuration, and metadata.  

  config ............................................................................................................................... 7.62ms DONE
  events ............................................................................................................................... 0.71ms DONE
  routes ............................................................................................................................... 5.56ms DONE
  views ............................................................................................................................... 28.61ms FAIL

   InvalidArgumentException 

  Unable to locate a class or view for component [heroicon-s-bars-3].

  at vendor/laravel/framework/src/Illuminate/View/Compilers/ComponentTagCompiler.php:311
    307▕         if (Str::startsWith($component, 'mail::')) {
    308▕             return $component;
    309▕         }
    310▕ 
  ➜ 311▕         throw new InvalidArgumentException(
    312▕             "Unable to locate a class or view for component [{$component}]."
    313▕         );
    314▕     }
    315▕ 

      +2 vendor frames 

  3   [internal]:0
      Illuminate\View\Compilers\ComponentTagCompiler::Illuminate\View\Compilers\{closure}(["<x-heroicon-s-bars-3 />", "heroicon-s-bars-3", "", ""])
      +7 vendor frames 

  11  [internal]:0
      Illuminate\Foundation\Console\ViewCacheCommand::Illuminate\Foundation\Console\{closure}(Object(Symfony\Component\Finder\SplFileInfo), "/Users/dwight/Sites/heroicons/resources/views/welcome.blade.php")

However, running php artisan view:cache runs fine.

Through playing with the optimize command I realised two things:

• If I comment out config or route caching from optimize then it works fine. Something that happens in the config:cache or route:cache command is affecting what happens in the view:cache command.
• The instance of the BladeCompiler from the container and the one that is received inside the ViewCacheCommand appear to be different (and the second doesn't have the Heroicon aliases available)

Steps To Reproduce

laravel new heroicons
cd heroicons
composer require blade-ui-kit/blade-heroicons

Add an icon to the welcome page: <x-heroicon-s-bars-3 />

[crynobone]

This seems to be a specific issue with how the package register view components (or how caching config) affects the way packages register the view components.

[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!

[PaperTurtle]

In the Illuminate\Support\ServiceProvider.php there is the method called loadViewsFrom. If you do run php artisan optimize check the output of the dd:

protected function loadViewsFrom($path, $namespace)
    {
        dd($this->app['view']->getEngineResolver()->resolve('blade')->getCompiler());
        $this->callAfterResolving('view', function ($view) use ($path, $namespace) {
            if (
                isset($this->app->config['view']['paths']) &&
                is_array($this->app->config['view']['paths'])
            ) {
                foreach ($this->app->config['view']['paths'] as $viewPath) {
                    if (is_dir($appPath = $viewPath . '/vendor/' . $namespace)) {
                        $view->addNamespace($namespace, $appPath);
                    }
                }
            }

            $view->addNamespace($namespace, $path);
        });
    }

You get the correct instance with the icons loaded. However, if you put the dd one line below:

protected function loadViewsFrom($path, $namespace)
    {
        $this->callAfterResolving('view', function ($view) use ($path, $namespace) {
            dd($this->app['view']->getEngineResolver()->resolve('blade')->getCompiler());
            if (
                isset($this->app->config['view']['paths']) &&
                is_array($this->app->config['view']['paths'])
            ) {
                foreach ($this->app->config['view']['paths'] as $viewPath) {
                    if (is_dir($appPath = $viewPath . '/vendor/' . $namespace)) {
                        $view->addNamespace($namespace, $appPath);
                    }
                }
            }

            $view->addNamespace($namespace, $path);
        });
    }

You get a completely new instance without new icons. I don't know where to go from here though, maybe someone with more knowledge can check this out. Also this does not apply when just running php artisan view:cache, you can put the dd wherever and it will give the correct instance with the icons.

[Mokei-it]

I have the same issue but only on production server on AlmaLinux 8.
On local I develop on windows 10 without errors

[dwightwatson]

Looks like Nuno solved this here: #51450

[bramdevries]

We still see this happening on 11.9.1. The fix in #51450 targets the 10.x branch, was it also fixed in 11.x?

[driesvints]

@bramdevries yes the change should be included. This was later on followed up by #51522. Wondering why it's still happening for you while others report it as fixed 🤔

[bramdevries]

If it helps:

We are only encountering this on our production environments when calling php artisan optimize. I see it occurring on two separate applications, both on 11.9.1 and PHP 8.3, that run on independent servers.

What's interesting is that it doesn't occur when running the command locally (either directly on the host, or with Sail).

[driesvints]

Hi @bramdevries. That leads me to believe there's something very specific going on with your production app. It's going to be hard to rule out what that is and you're the only one still reporting this issue. Therefor I think it's best that we close this issue and that you do some further investigation or use a workaround for now and report back if you find out more info about your specific use case.

[abishekrsrikaanth]

@driesvints I have the same issue with one of the forge servers, but again, I have multiple forge servers and only one of them is having this issue, still not sure why I am facing this issue. I am on the latest Laravel version and all my other packages including the blade-icons are updated to the latest versions.

Currently the resolution is to not call php artisan optimize but do the following

$FORGE_PHP artisan optimize:clear

$FORGE_PHP artisan config:cache
$FORGE_PHP artisan view:cache
$FORGE_PHP artisan route:cache
$FORGE_PHP artisan event:cache

[tonypiper]

I'm having this problem too, on Laravel 11.15. It doesn't fail on my local Mac Herd environment, but it does in production, PHP 8.3.8 on Forge.

I do have two icon sets installed - heroicons and phosphor-icons. I didn't publish the blade-icons config because it worked in dev. @abishekrsrikaanth and @bramdevries: do you have multiple icon sets installed too?

[MichaelMdp]

I can confirm we also run into this issue on our forge server. Not on our 'local' DDEV environment. Laravel 11.22.0 and PHP 8.3

[dwightwatson]

I think I've run into this problem again on a different project with a different server and may have narrowed it down to a PR in spatie/laravel-honeypot that updated the package's service provide to use callAfterResolving instead of facades.

I wonder if this use of callAfterResolving is a common thread and if the other people still having trouble here may have packages installed in their apps that use callAfterResolving or use it themselves?

[juliangums]

Also still breaking for me.
Also fine on local but breaks on Forge server.
php artisan view:cache also works on the server.