Update README.md

README.md

@@ -19,7 +19,9 @@
   - [When, Where, What, and How to Log Events](#when-where-what-and-how-to-log-events)
 - [Secrets and Configuration](#secrets-and-configuration)
   - [Secrets](#secrets)
-    - [Accessing Secrets](#accessing-secrets)
+    - [Important Security Note](#Important-Security-Note)
+    - [Original Secrets Handling Method](#Original-Secrets-Handling-Method)
+      - [Accessing Secrets](#accessing-secrets)
   - [Configuration](#configuration)
 - [Dependency Injection](#dependency-injection)
 - [HTTP Client](#http-client)
@@ -482,6 +484,45 @@ Secrets used by the application are accessed via environment variables. This acc
 > [!TIP]
 > Environment variables are configuration settings stored outside the application code. They're typically used to manage sensitive information—such as API keys—or to specify different configurations for various deployment environments (e.g., development, staging, production).
 
+
+#### Important Security Note
+
+> [!IMPORTANT]
+> This method of managing environment variables has known security issues. In later projects, this method has been retired in favor of passing in the environment variables directly to Flutter.
+> It is recommended to migrate any existing `dot_env` usage to this newer system. 
+
+Nowadays, environment variables are managed by passing the `.env` file into the Flutter/Dart command directly using `--dart-define-from-file=.env`. This requires a couple of changes, both in how the application is launched and how the environment variables are configured in the code.
+
+If you're using Visual Studio Code, you can simply edit your `launch.json` and include these lines:
+
+```json
+"toolArgs": [
+  "--dart-define-from-file=.env"
+]
+```
+
+Migrating the code allows you to _remove_ code, which is always nice. The `AppEnv` class can be removed, as it is no longer necessary. Now, your `EnvVar` enum can point directly to the environment varibles:
+
+```dart
+enum EnvVar {
+  /// The environment to use for the API calls. Returns either [sandbox] or [prod].
+  ///
+  /// Example `.env` configuration:
+  /// ```
+  /// API_ENVIRONMENT="sandbox"
+  /// ```
+  apiEnvironment(String.fromEnvironment("API_ENVIRONMENT")), // Note the direct reference to the environment variable
+  ;
+
+  /// The environment variable to use when retrieving the value of this [EnvVar].
+  final String value;
+
+  const EnvVar(this.value);
+}
+```
+
+#### Original Secrets Handling Method
+
 On a developer’s computer, environment variables are stored in `.env` files - one for each configuration (e.g., `.env.dev`, `.env.release`, etc.) and are _not_ checked into source control. Your application will read in variables from the `.env` file (which will be written to during a CI/CD build pipeline), so switching environments is as simple as copying the appropriate file to `.env`. To facilitate reading this file from the application, it should be included in the `assets` directory, such as `my_app/assets/.env`, with the `assets` directory included in `pubspec.yaml`.
 
 To facilitate this and make it as simple as possible for developers, a `Makefile` can be used:
@@ -535,7 +576,7 @@ enum EnvVar {
 }
 ```
 
-#### Accessing Secrets
+##### Accessing Secrets
 
 Accessing the secrets defined in the environment variables can be done via the `AppEnv`, provided they have been mapped to a corresponding `EnvVar` enum item: