-
Notifications
You must be signed in to change notification settings - Fork 85
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.
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
[eas-cli] Combine .env
and EAS environment variables for deploy
command
#2783
base: main
Are you sure you want to change the base?
Conversation
Subscribed to pull request
Generated by CodeMention |
c6eb6e7
to
04a5671
Compare
Size Change: +3.04 kB (+0.01%) Total Size: 53.4 MB
|
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #2783 +/- ##
==========================================
- Coverage 52.51% 52.49% -0.01%
==========================================
Files 583 583
Lines 22582 22589 +7
Branches 4452 4454 +2
==========================================
Hits 11856 11856
- Misses 10691 10698 +7
Partials 35 35 ☔ View full report in Codecov by Sentry. |
18ea25b
to
0be4a4f
Compare
✅ Thank you for adding the changelog entry! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Question for discussion: should this be the behavior for all commands that accept an --environment
flag? (update
, etc)
// NOTE: This is required for the .env resolution | ||
process.env.NODE_ENV = 'production'; | ||
// Resolve .env file variables | ||
const env: Record<string, string | undefined> = getEnv(params.projectDir).env; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is probably the question for @byCedric but doesn't the getEnv
have a side effect of overriding process.env
under the hood? I'm just curious?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh okay I see it will be fixed
// Load EAS Env vars into `env` object, keeping track of conflicts | ||
conflictingVariableNames = []; | ||
for (const variable of loadedVariables) { | ||
if (variable.value != null) { | ||
if (env[variable.name] != null) { | ||
conflictingVariableNames.push(variable.name); | ||
} | ||
env[variable.name] = variable.value; | ||
} | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe it doesn't really matter if we override .env
with EAS env vars here because npx expo export
that generates worker code always uses .env
with the highest priority either way. So this won't be the final env var resolution order in the final itself AFAIK because Expo CLI will load env vars from .env
for the second time on its own afterwards.
I would say that maybe we should:
- just use
.env
env vars when--environment
flag is not specified - just use EAS env vars when
--environment
flag is specified and skip using.env
env vars in Expo CLI by usingEXPO_NO_DOTENV=1
what do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We reasoned that during local development, it's very common to start adding new .env
vars while still not being ready to update the remote env variables. Hence, we wanted for them to be combined.
Without the combination it's easy to get into a situation where you'd have to always go into the EAS environment variables and modify them (or add temporary env vars) while deploying, for the worker deployments to have the desired set during test deployments.
We can add the EXPO_NO_DOTENV
flag for consistency though.
let env: Record<string, string | undefined>; | ||
): Promise<CreateManifestResult> { | ||
// NOTE: This is required for the .env resolution | ||
process.env.NODE_ENV = 'production'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Won't it affect all of the actions happening afterward? I discussed it with @brentvatne some time ago and we generally disliked that NODE_ENV
which can have many side effects is responsible for choosing which .env
file to use. I believe we should unset it somewhere.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As per re. which environment is chosen, we don't really want any non-production related .env
file from being chosen for the worker deployment, since logically the worker deployments are in a production environment once deployed
@kitten Oh okay I think this merging can actually work. You just need to always use One more thing that remains is that this logic would be different from how
I'm not saying this is necessarily bad I just want to make you aware of it. Why do I think this can possibly be confusing? We have 2 commands that work really similarly ( |
EAS Build is tricky here because in 50% of the cases people have |
Why
This allows
--environment
to be combined with local.env
files, outputting a warning when any variables conflict since EAS environment variables will take precedence.How
createManifestAsync
to returnmanifest
and conflicting variable namesgetEnv
and merge variables into theenv
objectTest Plan