What is the point to have the .env file?

[tekumai]

This is maybe a stupid question, but I don't understand how it works for a very typical use case.

We have BASE_URL parameter, which I can set in the .env file. This file is not included in the version control for a very valid reason: each developer can override the values to point to another environment or to use other credentials, etc.

But here comes the CI. Which also needs to read from .env file but it's not there and the build simply fails.

• Should I include the .env to version control? Then the whole point is lost, I could simply have config.dart file w/o additional dependency.
• Should I create the file on the CI? But why should I do this if I can simply incorporate environment variables which I can easily set on the CI, it works out of the box.

So, why should one use .env file over simply having config.dart which reads from environment variables (using Platform.environment['BASE_URL'])?

[AlexMcConnell]

How are you getting the variables in for local development? Are you just cluttering up your .bashrc with stuff? What happens when you're working on multiple projects that all want different values for the same variable? You could set them with Android Studio, but a lot of people are more comfortable doing a lot of things from the command line.

And how is your CI storing the values for the environment variables? Are you sure that all CIs work the same as the one you're using? What if the project is open source in a public GitHub repo or you don't even have a CI?

.env files solve a lot of general problems that may not be relevant to you individually but are certainly relevant to others.

[levous]

Typically .env files are intended to configure environment variables from a local file that should not be included in source control. In deployment scenarios, the secrets are then configured as environment variables. Flutter does not work like this as it does not read from the environment. Instead, the idiomatic approach is tp pass all configuration through --dart-define at build time. We are then required to build each app flavor in the style of mobile apps (dev, staging, production, etc). One must then also pass these arguments through debugging commands. Using a file makes the configuration obvious and centralized. It is very important to recognize that Flutter will expose these files since they are defined as assets. Therefore, nothing sensitive should be configured using this dotenv library. Ideally, minimal configuration is included in the file and sensitive configuration settings are retrieved from a secure, remote endpoint after authentication.
Since these env files are not secure, private, encrypted or protected, it makes sense to configure each environment in a plain file in your Flutter assets and then select the appropriate file based on some other variable. This could be a single --dart-defines at build time, a url domain pattern mapping in the code, etc. I recently learned it does no good to replace the config file post build in the build output directory. Flutter packages assets in an asset bundle and serves from that rather than the files in the assets directory. It is possible to do some http server trickery to overcome this.