LogicException: configuration files are not serializable.

[gregorip02]

When I try to execute the command php artisan optimize in production environments, I get a logical exception because the configuration offered by this package is not serializable.

Output

```php LogicException Your configuration files are not serializable. at vendor/laravel/framework/src/Illuminate/Foundation/Console/ConfigCacheCommand.php:71 67▕ require $configPath; 68▕ } catch (Throwable $e) { 69▕ $this->files->delete($configPath); 70▕ ➜ 71▕ throw new LogicException('Your configuration files are not serializable.', 0, $e); 72▕ } 73▕ 74▕ $this->info('Configuration cached successfully!'); 75▕ } 1 bootstrap/cache/config.php:781 Error::("Call to undefined method App\Nebula\Resources\UserResource::__set_state()") +27 vendor frames 29 artisan:37 Illuminate\Foundation\Console\Kernel::handle() ```

This is probably due to the fact that we store resource instances, dashboards, etc. in the configuration file. As a possible solution, we could give the user the option to assign namespaces as follows.

// config/nebula.php

return [
    'resources' => [
        UserResource::class,
    ],

    'dashboards' => [
       UserDashboard::class,
    ],
];

I could try to solve it, what do you think?

[Larsklopstra]

I'm thinking about deprecating the config, and implement middleware as a service provider (cc @ryangjchandler) or just stick with what Ryan made already - adding resources to the Nebula facade

[Larsklopstra]

I've never heard of php artisan optimize is it a Laravel 8 thing?

[gregorip02]

@Larsklopstra This cache the framework bootstrap files.. It's a shorter way of doing.

php artisan route:cache
php artisan config:cache

Commonly in production environments.

[Larsklopstra]

Ah, that makes more sense to me. What do you propose, ditching resources/pages in configs?

[gregorip02]

We would keep the same structure in the configuration, but instead of receiving instances of the resources/dashboards, we would delegate the developer to include the class namespace, and instantiate it when trying to access them.

[ryangjchandler]

I'd do what @gregorip02 has suggested. Use the FQN of the class to instantiate it. This might mean that we end up instantiating the same class multiple times though, whereas before the config is a singleton so use have access to the same instance in a single request.

[Larsklopstra]

Closing since this is a stale issue. Please create a PR (or follow up issue) if this is still a problem