Doesn't this create a circular dependency in case you changed something in your Dotfile?

As the symfony command would itself use symfony for dumping the vars, it might run into problems. By being a composer command it is decoupled from Symfony, which is a good thing (in this case).

A solution would be to add the command as standalone executable.

A solution would be to add the command as standalone executable.

That's what I'm thinking about. Just forgot to write it down!

The core of the code we're talking about would look like this (copy-pasted from https://github.com/symfony/flex/blob/master/src/Command/DumpEnvCommand.php):

function dumpEnv(string $path, string $env)
{
        $globalsBackup = [$_SERVER, $_ENV];
        unset($_SERVER['APP_ENV']);
        $_ENV = ['APP_ENV' => $env];
        $_SERVER['SYMFONY_DOTENV_VARS'] = implode(',', array_keys($_SERVER));
        putenv('SYMFONY_DOTENV_VARS='.$_SERVER['SYMFONY_DOTENV_VARS']);

        try {
            $this->loadEnv($path);
            unset($_ENV['SYMFONY_DOTENV_VARS']);
            $vars = $_ENV;
        } finally {
            list($_SERVER, $_ENV) = $globalsBackup;
        }

        $vars = var_export($vars, true);
        $vars = <<<EOF
<?php

// This file was generated by dumping the "$env" env

return $vars;

EOF;
        file_put_contents($path.'.local.php', $vars, LOCK_EX);
}

I wouldn't make this a command in the component.
Maybe a method on Dotenv? Someone that cares would need to make it happen :)

@fbourigault up for a PR? Otherwise we might close I think.

It’s still on my todo list ;)

this is a good idea. The dump-env shouldn't be dependent on flex please.

Well, the component might expose its own script vendor/bin/dump-env rather than hooking into bin/console if that causes an issue with circular references.

Thank you for this suggestion.
There has not been a lot of activity here for a while. Would you still like to see this feature?

This is implemented since Symfony 5.4 🎉 (see #42610)