Skip to content

RFC for dynamically imported ENV variables. #8

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
weerd wants to merge 2 commits into
base: main
Choose a base branch
from
Draft

RFC for dynamically imported ENV variables. #8

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
96b5e25
RFC for dynamically imported ENV variables.
weerd Jan 13, 2020
8db3c02
Forgot to push this up.
weerd Jan 13, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 15 additions & 0 deletions 008-dynamically-imported-environment-variables.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,15 @@
# Dynamically Imported ENV Variables

Establishing a system where environment variables declared in an environment's `.env` file are dynamically imported both on the backend and the frontend will help simplify the use of test variables and feature flags within Phoenix.

**Discussion:** <https://github.com/DoSomething/rfcs/pull/8>

## Problem

We do not currently utilize setting environment variables in the `.env` as much as we could within Phoenix because it is cumbersome to do so. Each new variable added to the file requires additional code updates in different locations to make the variable available to the backend as well as the frontend. Due to this process, most developers prefer to use env variables only for the backend and setting hard-coded constants in a variety of different JavaScript files for the frontend. This can lead to issues with inconsistency in variables and lack of confidence in knowing that a feature flag or test suite variable is readily available.

Additionally, since environment specific variables are typically hard-coded for the front-end, the JavaScript code tends to require checks against which environment the code is running on to ensure it is using the correct variable.

## Proposal

It could be possible that by generating a standard naming convention for these types of environment variables (used for feature flags and test suite specific runs), we could dynamically import variables set within the `.env` file to automatically become available for both the backend and the frontend. Developers would only need to create the variable in the `.env` file and they could be confident in knowing it would become available universally.