Add craft config/cache as a console command

[khalwat]

Something analogous to to the Laravel artisan config:cache would be really useful for production deployment: https://laravel.com/docs/master/configuration#configuration-caching

It could combine all of the craft/config files into one cached file for faster loading, and take all of the PHPdotenv settings and coalesce them into this cached config file so that it could be loaded quickly, without having to parse the .env for every request.

As per the PHPdotenv docs:

phpdotenv is made for development environments, and generally should not be used in production. In production, the actual environment variables should be set so that there is no overhead of loading the .env file on each request. This can be achieved via an automated deployment process with tools like Vagrant, chef, or Puppet, or can be set manually with cloud hosts like Pagodabox and Heroku.

This is a perfect type of thing to be added as a Craft console command via craft config/cache or such. If the cache file exists, great, use it, and don't parse anything in craft/config. If it doesn't exist, parse as normal.

You'd essentially just be preflighting something that's the same for every request, and eliminating unnecessary overhead.

[khalwat]

Dotenvy gets us part of the way there, anyway: https://github.com/nystudio107/dotenvy

[acalvino4]

Is this implemented in craft cms core, or should we still be using dotenvy?

[khalwat]

It's not implemented in Craft core... but I think something like it would be nice to see.

In terms of real-world performance, I'm not sure how much of a difference it will make for the lifecycle of a Craft request, though.

[acalvino4]

In itself, I'm sure not much...but multiple micro-optimizations do add up, so spending the time to add them to core and benefit thousands of sites (even if in a very small way) can't be too easily dismissed. Probably won't worry about it for my sites though.

[khalwat]

Good writeup on what artisan config:cache does in Laravel: https://medium.com/@yish/how-does-config-cache-works-in-laravel-9f5dc1be710b

[timkelty]

I'm not sure about the value here, because of this:

Sure, this would help if you're using a .env file in production. But if you're doing that, you're already going down the wrong path, at least going by most dotenv guidelines.

Generally, in production, you'd load this env using your infrastructure (e.g Docker, source .env, etc), and not ship a .env file at all with your production code.

Sure, there may be some benefit to combining all the files from config/* into one PHP file, but that seems like an extreme micro-optimization, especially considering OPCache.

[timkelty]

I understand that people still do probably end up shipping .env files in production, either out of convenience or ignorance…but I'm not sure how I feel about Craft catering to that practice.

Sounds like a good plugin to me :)

[michaelrog]

I will ship .env to production til I die. Anyone who needs to remind me how this is wrong will literally spend more seconds typing the sentence than the entire cumulative overhead of phpdotenv across the entire lifespan of all my projects ever. #coolguysdontlookatexplosions 😎

[khalwat]

Generally, in production, you'd load this env using your infrastructure (e.g Docker, source .env, etc), and not ship a .env file at all with your production code.

I wish that were true, and agree it should be ideally how things are done -- but I think it's actually a rarity that it's actually done this way, from what I've seen anyway.

I don't think solving this with "Craft Cloud" is a realistic way to consider the problem solved (though you can solve it there too, just like Matt has with Servd.host), because not everyone is going to use it.

In any event, here's to hoping that a focus on performance is a priority as features are being added to Craft.

[timkelty]

Quick note here: I'm in favor of this idea, but one roadblock at the moment is the circular dependency between the Config and Cache components. At the moment, Cache depends on Config, so it makes it difficult to cache the config using the Cache component.

That said, I think Laravel's appoach actually writes a php file, not to cache, so maybe that isn't a concern.