You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In this case the app code should check the type of environment and then declare different strategies. It would be useful to just declare composable variables in the .env file.
Help
I could open a PR if you agree with the implementation.
From my point of view env-schema should provide a boolean expand options defaulted to false. When expand=true, internally use dotenv-expand.
The text was updated successfully, but these errors were encountered:
I could open a PR if you agree with the implementation. From my point of view env-schema should provide a boolean expand options defaulted to false. When expand=true, internally use dotenv-expand.
Why should it default to false? is there some performance issue?
🚀 Feature Proposal
It would be great to add the ability to interpolate variables.
Motivation
Often boxes come with some env variables that you want to use to declare other environment variables.
Example
Given the machine comes with an env variable like the following:
When in
.env
file we define the followingThen the variable should be valued like:
This could be done in the app code, but consider the scenario where for local development the service url needs to have the following value:
In this case the app code should check the type of environment and then declare different strategies. It would be useful to just declare composable variables in the
.env
file.Help
I could open a PR if you agree with the implementation.
From my point of view
env-schema
should provide a booleanexpand
options defaulted tofalse
. Whenexpand=true
, internally use dotenv-expand.The text was updated successfully, but these errors were encountered: