-
-
Notifications
You must be signed in to change notification settings - Fork 495
PHPUnit: use a .env file #465
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request passes validation.
Have you seen #408 and related issues?
👍 I've seen multiple dotenv components using this. E.g: |
|
||
use Symfony\Component\Dotenv\Dotenv; | ||
|
||
(new Dotenv())->load(__DIR__.'/../.env', __DIR__.'/../.env.test'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If an env var is specified in both, .env.test
wins, right?
Also, if we do this for the test
environment, people will ask for it for other environments too. And I think they're right - it would be simpler to have a file like this that will load from .env.{ENV}
(if it exists) and to require that from index.php
and console
. console
is especially important - we don't want someone to run a bin/console
test with --env=test
and have different environment variables than their tests.
Check out https://github.com/symfony/recipes/pull/408/files - where we working on something similar to this. We were also putting even some extra code into this central "bootstrap" file to fully remove the duplication between index.php
, console
(and now) the test bootstrap.
@@ -0,0 +1,2 @@ | |||
APP_ENV=test | |||
APP_SECRET=s$cretf0rt3st |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any benefit to defining these? The APP_ENV
will always already be set. Perhaps just leave it blank, but with a comment that overrides can go here?
I’m with totally for “copying” the behavior of Create React App for several reasons:
I’ll update the PR accordingly tomorrow |
Superseded by #466. |
…s dotenv behavior (dunglas) This PR was merged into the 4.2-dev branch. Discussion ---------- [DotEnv] Add a new loadForEnv() method mimicking Ruby's dotenv behavior | Q | A | ------------- | --- | Branch? | master | Bug fix? | no | New feature? | yes | BC breaks? | no <!-- see https://symfony.com/bc --> | Deprecations? |no <!-- don't forget to update UPGRADE-*.md and src/**/CHANGELOG.md files --> | Tests pass? | yes <!-- please add some, will be required by reviewers --> | Fixed tickets | helps for symfony/recipes#465, symfony/recipes#408 | License | MIT | Doc PR | todo This PR adds a new `loadForEnv()` method that mimics the behavior of [Create React App](https://github.com/facebook/create-react-app/blob/master/packages/react-scripts/template/README.md#what-other-env-files-can-be-used), [Rails' DotEnv](https://github.com/bkeepers/dotenv#what-other-env-files-can-i-use) and probably some other libs: `DotEnv::loadForEnv()` will load the following files, starting from the bottom. The first value set (or those already defined in the environment) take precedence: - `.env` - The Original® - `.env.dev`, `.env.test`, `.env.prod`... - Environment-specific settings. - `.env.local` - Local overrides. This file is loaded for all environments _except_ `test`. - `.env.dev.local`, `.env.test.local`, `.env.prod.local`... - Local overrides of environment-specific settings. The plan is to use this method in the default SF installation (symfony/recipes#466). Commits ------- 774a78c [DotEnv] Add a new loadForEnv() method mimicking Ruby's dotenv behavior
Having to modify both
.env
and andphpunit.xml.dist
when adding an environment variable is tedious and error prone.Storing env vars in different formats (XML and
.env
) also leads to weird bugs such as #317.With this PR, in test mode
.env
and.env.test
files are always loaded..env.test
allows to override env vars for this env.Not related with this PR: I don't really understand why we need both
.env
and.env.dist
. As.env
file must not be used in production anyway, can't we have only a (versioned).env
file and get rid of the.dist
one?For people not using Docker/Vagrant/etc, we may allow to override the values of the
.env
file in a.env.local
file (that will not be versioned).Even if we want to keep the
.dist
file, cannot we always load it along with.env
? Then we'll be able to only use.env
to override some vars (the secrets) instead of having to copy the full content in both. wdyt?