Documented the loadForEnv() method #10626
Conversation
|
|
||
| .. versionadded:: 4.2 | ||
| The ``Dotenv::loadForEnv()`` method was introduced in Symfony 4.2. | ||
|
|
||
| You should never store a ``.env`` file in your code repository as it might |
There was a problem hiding this comment.
This sentence should be remove in favor of the paragraph you introduced, right?
| the app on your local machine. The other two optional files (``.env`` + | ||
| "environment name" + ``.local`` and ``.env`` + "environment name") work | ||
| similarly, but they are specific to some environment. | ||
|
|
There was a problem hiding this comment.
May I suggest to add the following:
| ``DotEnv::loadForEnv()`` implements the exact same behavior than Ruby's `dotenv library`_ and `Create React App's .env support`_. These projects provide extensive documentation about environment variables handling, that is worth reading. |
| @@ -112,3 +148,4 @@ Embed commands via ``$()`` (not supported on Windows): | |||
|
|
|||
| .. _Packagist: https://packagist.org/packages/symfony/dotenv | |||
| .. _twelve-factor applications: http://www.12factor.net/ | |||
| .. _`app config recommendations`: https://12factor.net/config | |||
There was a problem hiding this comment.
| .. _`app config recommendations`: https://12factor.net/config | |
| .. _`app config recommendations`: https://12factor.net/config | |
| .. _`dotenv library`: https://github.com/bkeepers/dotenv | |
| .. _`Create React App's .env support`: https://facebook.github.io/create-react-app/docs/adding-custom-environment-variables#what-other-env-files-can-be-used |
| $dotenv->loadForEnv('dev', __DIR__.'/.env'); | ||
| // Looks for env vars in these files (and in this order): | ||
| // .env.dev.local | ||
| // .env.local |
There was a problem hiding this comment.
Will be loaded after .env.dev
Hmm. Are you sure? I didn't check the code, but if it's true it's not respecting the same priorities as https://github.com/bkeepers/dotenv/blob/master/README.md#what-other-env-files-can-i-use, i.e:
.env.[env].local.env.local.env.[env].env
Also, what about using the same presentation as bkeepers/dotenv? (The table with complementary information)
There was a problem hiding this comment.
But https://facebook.github.io/create-react-app/docs/adding-custom-environment-variables#what-other-env-files-can-be-used does load .env.local after .env.[env]...
IMHO, loading .env.local before .env.[env] makes more sense, as x.local should always allow override. Either you use .env.local to override for all environments, either you use .env.[env].local for a specific env. But .env and .env.[env] will only contains sensible defaults, so .env.[env] should not have precedence over .env.local.
| // .env | ||
|
|
||
| The ``.env`` file should be committed to the shared repository and contains the | ||
| default env var values for the app. The optional ``.env.local`` file shouldn't |
There was a problem hiding this comment.
| default env var values for the app. The optional ``.env.local`` file shouldn't | |
| default env var values for the app. The ``.env`` file should contain development-only settings. It **must not** contain any settings used in production. They are placeholder values helping during the onboarding process. The optional ``.env.local`` file shouldn't |
| // .env.test.local | ||
| // .env.test | ||
| // .env | ||
|
|
There was a problem hiding this comment.
| Similarly to ``DotEnv::load()``, ``DotEnv::loadForEnv()`` never overwrites existing environment variables, nor variables defined by files loaded previously. For instance, if the same variable is defined in both `.env` and `.env.test.local`, the value will be the one defined in `.env.test.local`, because this file is loaded first by ``DotEnv::loadForEnv()``. |
There was a problem hiding this comment.
I would add somewhere something similar to https://github.com/bkeepers/dotenv/blob/master/README.md#can-i-use-dotenv-in-production last paragraph:
please note that env vars that are general to all environments should be stored in .env. Then, environment specific env vars should be stored in .env.<that environment's name>.
i.e no need to repeat all env vars. Only the ones likely to be specific for the target env.
| $dotenv->loadForEnv('dev', __DIR__.'/.env'); | ||
| // Looks for env vars in these files (and in this order): | ||
| // .env.dev.local | ||
| // .env.local |
There was a problem hiding this comment.
Will be loaded after .env.dev
Hmm. Are you sure? I didn't check the code, but if it's true it's not respecting the same priorities as https://github.com/bkeepers/dotenv/blob/master/README.md#what-other-env-files-can-i-use, i.e:
.env.[env].local.env.local.env.[env].env
Also, what about using the same presentation as bkeepers/dotenv? (The table with complementary information)
| // .env.test.local | ||
| // .env.test | ||
| // .env | ||
|
|
There was a problem hiding this comment.
I would add somewhere something similar to https://github.com/bkeepers/dotenv/blob/master/README.md#can-i-use-dotenv-in-production last paragraph:
please note that env vars that are general to all environments should be stored in .env. Then, environment specific env vars should be stored in .env.<that environment's name>.
i.e no need to repeat all env vars. Only the ones likely to be specific for the target env.
|
But, those changes I believe also apply to 3.4 |
|
Should be updated to account for #29129 |
|
And I think there are / will be a few more recipe changes still? Once those finish, we can finish this up as quickly as possible |
|
Note that the method changed to loadEnv() with different signature and behavior. |
|
I'm closing this because the handling of .env files is still "a moving target" and too many things are still changing. Let's work on this again after things settle down. Thanks! |
Fixes #10607.