laravel shift, upgrade to 5.2 - use config() instead of env()

I have never used it, I just follow the upgrade guide and look through the code. However, I think it is just referring to hard coded configs instead of using ->config('CONFIG_ITEM') to access.

I'd say it's just referring to this: https://laravel.com/docs/5.3/upgrade

If you are calling env from within your application, it is strongly recommended you add proper configuration values to your configuration files and call env from that location instead, allowing you to convert your env calls to config calls.

Its easy - if you have gtm_id for example add to config.

'gtm_id' => env('GTM_ID', 'defaultvariable')

"use env() from configuration files" as mentioned.

Thanks. I understand how to do it, what I don't understand is why?

Why the added abstraction? I have most my application variables defined in an .env file. Why define them again in a .config file, just to re-declare them?

Can someone provide a valid reason to proxy .env variables through a .config file? Is there something about the framework I am missing?

In my opinion possible reasons could be:

• Naming standard: Env variables seems to be using slightly different convention (all caps).
• Security: Some env variables might come from foreign origins (like htaccess or vhosts) and might need additional filtering
• Control: By using additional layer you can have more control over variable from repository (for example default values).

One reason is config caching:

To give your application a speed boost, you should cache all of your configuration files into a single file using the config:cache Artisan command. This will combine all of the configuration options for your application into a single file which will be loaded quickly by the framework.

https://laravel.com/docs/5.3/configuration#configuration-caching

Most of the replies have already hit the various reasons why using env()only in your configuration files and config() everywhere else is preferred. However, as the creator of Laravel Shift, I wanted to clarify.

This was indeed adapted from the Laravel Upgrade Guide. It's underlying reason primarily has to do with caching, which provides performance benefits.

There's also an additional clarity from the abstraction. That is, using env(), while more direct, limits the source of your values, whereas config() sources multiple. config also reads more clearly that this is a configuration value.

Finally, on a separate but related note, I'd recommend placing custom configuration values in a separate configuration file. For example, config/custom.php. This not only provides clarity, but makes it easier to maintain and upgrade core configuration files between versions.

I'll chime in here as well because I haven't seen anyone else mention it.

As @nztim mentioned, the config files are cached so anytime you call config(...) you're reading from a cached array. So there is a speed benefit.

But it's more than that. If you use env(...) outside of these cached config files, you will be reading directly from your .env file every time you call this function, which will almost certainly cause issues when you have a rapid succession of requests in your application, where the .env file can't be read (due to file locking issues, IIRC). I ran into this issue myself.

Read more here: https://laracasts.com/discuss/channels/general-discussion/laravel-intermittently-does-not-pull-from-environment-variables-correctly

Basically, the only place you ever use the getenv() or env() functions are in your config files (present in the /config/ directory). Then, you run the command php artisan config:cache which caches all those files. Then, you are only pulling your ENV variables once, upon deployment, and you won't have this issue anymore where there is a problem reading ENV variables (which is a complex issue involving more than just Laravel).

Excellent description to why this is necessary. Thanks!