Support for multiple .env file.

I was thinking it would be great to have different .env files in CI4.

Loading order: 

1. .env
   
2. .env.dev (optional file) (overrides keys from previous one if exist in this one).
   
3. .env.prod (optional file) (overrides keys from previous ones if exist in this one).
   
4. .env.test (optional file) (overrides keys from previous one if exist in this one).
   

When developing, CI use .env file to manipulate config files. But many developers use it in and extended manner.

For example, different mail api credentials for development and production.

• Different slack webhook credentials for dev, test, and prod environments.
  
• Different JWT secrets and/or ttl for dev, test, and prod environments.
  
• For commands, different path to php definition for shared hosting accounts.
  

Can multiply scenarios. 

What I suggest is also being used somehow by Symfony and Laravel.

I wanted to override with a Config\DotEnv extend Codeigniter\Config\DotEnv but not recognized my file. Yet, also thinking should be a out-of-box feature. 

Thanks for your time.

I was thinking it would be great to have different .env files in CI4.

Loading order: 

1. .env
   
2. .env.dev (optional file) (overrides keys from previous one if exist in this one).
   
3. .env.prod (optional file) (overrides keys from previous ones if exist in this one).
   
4. .env.test (optional file) (overrides keys from previous one if exist in this one).
   

When developing, CI use .env file to manipulate config files. But many developers use it in and extended manner.

For example, different mail api credentials for development and production.

• Different slack webhook credentials for dev, test, and prod environments.
  
• Different JWT secrets and/or ttl for dev, test, and prod environments.
  
• For commands, different path to php definition for shared hosting accounts.
  

Can multiply scenarios. 

What I suggest is also being used somehow by Symfony and Laravel.

I wanted to override with a Config\DotEnv extend Codeigniter\Config\DotEnv but not recognized my file. Yet, also thinking should be a out-of-box feature. 

Thanks for your time.

I fully agree with this proposal. Could be really useful.

It seems an idea to make the world complicated.

If you build development environment, it needs only one .env for development.
If you build production environment, it needs only one .env for production.

Why do you need two .env files?

ci-phpunit-test | CodeIgniter Testing Guide | CodeIgniter 3 to 4 Upgrade Helper

Hi Kenjis,

When working in development environment, when we want to see/test how it is in production environment, it is being needed. It is not a personal preference actually, Symfony has it too.

It's been a while I asked this question, I ended up with a command that symlinks .env file. Here is the command:

PHP Code:

namespace App\Commands;

use CodeIgniter\CLI\BaseCommand;
use CodeIgniter\CLI\CLI;
use Symfony\Component\Process\Process;

class LinkEvnFileCommand extends BaseCommand
{
    protected $group = 'Generators [PRIME]';
    protected $name = 'make:env';
    protected $description = 'Creates a symbolic .env from .env.{local|remote} file';

    public function run(array $params)
    {
        $envFiles = [
            '.env.local',
            '.env.remote',
        ];

        if (file_exists(ROOTPATH.'.env')) {
            CLI::write('.env file found. Linking to be skipped!', 'yellow');
        } else {
            $copiedEnvFile = '';
            foreach ($envFiles as $envFile) {
                if (true === file_exists(ROOTPATH.$envFile)) {
                    $process = new Process(['ln', '-svi', $envFile, '.env'], ROOTPATH);
                    $process->run();
                    $copiedEnvFile = $envFile;
                    break;
                }
            }

            if (false === empty($copiedEnvFile)) {
                CLI::write($copiedEnvFile.' linked to .env symbolically.', 'green');
            } else {
                CLI::write('No .env file created. Make sure you have .env.local or .env.remote file.', 'red');
            }
        }

        CLI::newLine();
    }
} 


Why do you test how production works on the development environment?
If you do so, you need to know the secrets for the production environment.
It is dangerous practice.

And yes, with your command, you can make the .env file that you need. 
It is simpler and better, I think.

Also, if you really need the solution like Symfony, you can use symfony/dotenv with CI4.
https://github.com/symfony/dotenv

ci-phpunit-test | CodeIgniter Testing Guide | CodeIgniter 3 to 4 Upgrade Helper

Would just add blot to CodeIgniter 4.

KISS.

What did you Try? What did you Get? What did you Expect?

Joined CodeIgniter Community 2009.  ( Skype: insitfx )

It seems an idea to make the world complicated.

If you build development environment, it needs only one .env for development.
If you build production environment, it needs only one .env for production.

Why do you need two .env files?

The reason is that when working with PhpStorm (or with an FTP for example) on a local DEV machine each deployment/synchronization to a pre-production or production server overwrites the .env file with the development .env file. 
Of course, you can manually exclude it from synchronization or rename it, or many other "semi manual" things but at the end, you just can accidentaly overwrite the target .env file or forget to update it as well.


The different config\development and config\production folders were very convenient in CI3 to manage this kind of case. It was just simple and easy.

Regarding the danger, it is no less dangerous to keep a development.env and production.env files next to a single .env file, which you must constantly rename. 
Pushing one or pushing 3 .env to GIT is another debate and is dangerous regardless.

I say, if you put a file with the secrets for production on your development machine, it is dangerous practice.
You should not do it, and you should not know the secrets as a developer.
The secrets should be accessible only by a server admin.

ci-phpunit-test | CodeIgniter Testing Guide | CodeIgniter 3 to 4 Upgrade Helper

If the local .env file overwrites the server .env during deployment, then the deployment process is problematic.
The local .env is for local use and should not be transferred to the server.
Is it a limitation of the tool that it cannot be excluded?

ci-phpunit-test | CodeIgniter Testing Guide | CodeIgniter 3 to 4 Upgrade Helper

In PHPStorm it is very easy to exclude a file to upload during synchronisation.
More information can be found here:
https://www.jetbrains.com/help/phpstorm/...yment.html