Thanks to visit codestin.com
Credit goes to github.com

Skip to content

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

Closed
wants to merge 1 commit into from
Closed

PHPUnit: use a .env file #465

wants to merge 1 commit into from

Conversation

dunglas
Copy link
Member

@dunglas dunglas commented Sep 20, 2018

Q A
License MIT

Having to modify both .env and and phpunit.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?

Copy link

@ghost ghost left a 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.

@ogizanagi
Copy link
Contributor

Have you seen #408 and related issues?
To me as mentioned in #366 (comment), another issue to consider with the current situation is we cannot easily execute a sf command in any environment.

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).

👍 I've seen multiple dotenv components using this. E.g:


use Symfony\Component\Dotenv\Dotenv;

(new Dotenv())->load(__DIR__.'/../.env', __DIR__.'/../.env.test');
Copy link
Member

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
Copy link
Member

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?

@dunglas
Copy link
Member Author

dunglas commented Sep 20, 2018

I’m with totally for “copying” the behavior of Create React App for several reasons:

  • it works smoothly and is easier to use for developers than what we do now
  • developers coming from the JS world are used to this behavior
  • something more “personal”: api-platform/api-platform comes with both Symfony Flex and Create React App (it’s a monorepo containing the server and the client code), uniformizing will improve our DX a lot

I’ll update the PR accordingly tomorrow

@dunglas
Copy link
Member Author

dunglas commented Sep 21, 2018

Superseded by #466.

@dunglas dunglas closed this Sep 21, 2018
fabpot added a commit to symfony/symfony that referenced this pull request Oct 26, 2018
…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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants