[5.9] Per environment config caching #28998
Replaced by: laravel/laravel#5050
This PR is part one of two PRs (part two). Together these PRs can reduce the boot time of the Kernel during a test run by ~50% without any additional work by the developer. This will only really have an impact on a larger test suite, but personally I think it is a worthwhile thing to consider.
I recently did some benchmarking (which I wrote about over here) of Laravel's
I found that I was able to reduce this overhead by 50% if I first cached the configuration, just like you would in production. The test suite ended up with the following durations:
Doing this is good for a couple of reasons:
There are however a few issues.
I am proposing we introduce 2 new features.
Per environment config caching
When you cache the config, it will now use the following cache files...
php artisan config:cache # bootstrap/cache/config.php php artisan config:cache --env=testing # bootstrap/cache/config.testing.php php artisan config:cache --env=whatever # bootstrap/cache/config.whatever.php
A PHPUnit Listener
The PHPUnit listener will cache the config for the test environment before a test is run. Because it is in "User land" it is 100% opt-in. If you don't want it, don't use it.
One handy thing about running the cache command in a PHPUnit listener (as opposed to say in a composer script) is that it will already have the environment variables from the
The PR for the listener is over here: laravel/laravel#5049
If this kind of thing is wanted in core, there is also potential to cache routes, events, etc. But I wanted to see if it was wanted before putting in the work to do all of them.
An alternative approach
In my first run at this I was having issues using the
This new PR to
@timacdonald would you not be able to set the env var
@matthewnessworthy I did consider that variable (and mentioned it in my first comment) but I ran into some issues. That being said, I didn't actually document what they were, and I've also change my approach and have a better understanding of this part of the system, so it might be worthwhile giving it another spin. Will report back shortly.
Is this still the case?
If the environment variable to a different cache file works, it's only relevant to clear the config cache once before the test suite which should be rather easy to detect.