Envify
A better and probably safer way to handle environment variables in Flutter.
To read why this is better/safer in details, skip to the motivation section.
Table of Contents
Overview
For a .env file like this,
KEY=VALUE
and a class like this,
part 'env.g.dart';
@Envify()
abstract class Env {
static const key = _Env.key;
}
envify will generate the part file which contains the _Env class with value for KEY loaded from the .env file.
Now you can use the Env.key,
print(Env.key); // "VALUE"
Installation
Add both envify and envify_generator as dependencies,
dependencies:
envify: any
dev_dependencies:
envify_generator: any
build_runner: any
If you already don't have build_runner, you need to add it too.
Usage
Add a .env file at the root of the project. Syntax and rules for the file can be viewed at dotenv rules. Define API for generation at lib/env/env.dart (you can use any file at any path but I would recommend using this so that you don't forget to add this file to .gitignore later).
Don't forget to add both
.envfile andenv.g.dartto.gitignore! Otherwise, you might expose your environment variables.
// env/env.dart
import 'package:envify/envify.dart';
part 'env.g.dart';
@Envify()
abstract class Env {
static const key = _Env.key;
}
Then run the generator,
# dart
pub run build_runner build
# flutter
flutter pub run build_runner build
API Documentation
Change .env file path
You can change the file to get the data to generate for, in the @Envify annotation. By this API, it is also possible to have multiple environment variables classes for multiple occasions.
@Envify(path: '.env.development')
abstract class DevEnv {}
@Envify(path: '.env.production')
abstract class ProdEnv {}
Change generated class name
By default, the generated class will be named as the name of the annotated class with a _ prefixed. You can change it using the name field. Note that the _ will always be prefixed.
@Envify(name: 'Secrets')
abstract class Env {
static const key = _Secrets.key;
}
Motivation
I needed to use environment variables in a recent Flutter project, and the option available was flutter_dotenv which is a package tweaked over the dotenv package. Because the dotenv package only handles the environment variables only during a process, the flutter_dotenv package hack its way by exporting the .env file into the assets and loading the file during the app runtime.
But there were some problems with this approach that I noticed,
-
The asset directory can be accessed directly through unzipping the APK, thus easily exposing the environment variables,
-
The loading of the environment variables takes time, This is ok in a dart process because it will only load the first time during the process's lifetime, but in this case, it will load every time you open the app.
-
Because the variables were loaded on the runtime, you can't access them as constant expressions for source code generation, For example, you won't be able to use them with tools like
json_serializableandretrofitwhich require constant value configurations via annotations.
Envify solves all the presented issues by using code generation.
Features
-
Envify will generate code for the user defined set of keys with the values from the environment variables file which is
.envby default. Since the generated code is part of the source, it will be passed through the obfuscating/compiling process during compile time making it harder to reverse engineer. -
Envify will only generate fields that the user has passed making it handy to use with shared environment variables between multiple projects.
-
Changing between multiple environment files like
.env.productionand.env.developmentis also easier because the user can configure which file to load environment variables from via the@Envifyannotation. -
Users can also pass optional field types during the definition, which envify will use to cast the values of generated fields. But since it's not appropriate to store large values except strings in the
.envfile, only literal types likeint,double,num,bool, andStringcan be parsed. If type is optional or else,Stringwill be used as default. -
The generated fields will be constant expressions that can be used within source code generation and every other place user needed.
Acknowledgement
To make this project possible, I had to learn about code generation which I did not know anything about. To learn, I had to read source codes of large code generator projects like json_serializable and many others. So certain parts like how the tests are written, and how the API is structured are influenced by those projects. The parser used in the generator comes from the dotenv package.
Also, using a class as an abstraction layer instead of directly accessing the generated code is a design decision I made so that the error when the env.g.dart part file is not generated, won't spread out through the project. Now even when the part file is not generated yet, the error only stays in the env.dart file.
License
MIT © Frenco Jobs
27 Nov 11, 2022
3 Jul 20, 2022
5 Jul 10, 2022
1.7k Dec 28, 2022
3.2k Jan 8, 2023
268 Jan 1, 2023
7.4k Jan 2, 2023
12 Oct 24, 2022
1.8k Dec 30, 2022
7 Nov 2, 2022
35 Oct 22, 2022
356 Dec 16, 2022
3.5k Jan 4, 2023
1k Jan 7, 2023
278 Dec 12, 2022
88 Oct 28, 2022
1.1k Jan 6, 2023
49 Oct 12, 2022
37 Jul 10, 2022