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
We often want to run a task that has multiple configurations with the ability for each configuration to have its own envFile.
For example, you may have multiple configurations (Testing, Staging, Production) for run-app. We want each configuration to use a different env file so they use and point at different URLs. We are currently unable to do this. To acheive something similar, we have to either:
Duplicate the tasks, but just change the target name. E.g. run-app-in-testing, run-app-in-staging etc.
Do some transformation on the .env file before running the task
If envFiles with both the target and configuration name were automatically picked up and parsed. It would solve a few issues around unnecessarily having multiple targets when configurations should be used or the need to transform env files.
It looks like this idea has been raised within other issues/ feat requests but not implemented:
A change to getDotenvVariablesForTask() in packages/nx/src/tasks-runner/forked-process-task-runner.ts to include the above search patterns. This would allow the configuration name to be used automatically in all executables.
Alternate Implementations
Another alternative is for Nx packages to extend their options to allow an env file path.
Please do shout though if I have missed something and there is a better alternative than making a change to the task runner process, I'm not familiar with the Nx code base.
The text was updated successfully, but these errors were encountered:
Hywie
changed the title
Allow NX, by default, to parse env files by target configuration name
Allow Nx, by default, to parse env files by target configuration name
Feb 11, 2023
Description
Currently, Nx uses the target name when searching for env files but does not take into account the configuration of the target.
The current implementation looks for:
.env
.local.env
.env.local
.[target-name].env
.env.[target-name]
apps/my-app/.env
apps/my-app/.local.env
apps/my-app/.env.local
apps/my-app/.[target-name].env
apps/my-app/.env.[target-name]
I suggest we include the configuration name when looking for env files. That would allow us to look for:
.env
.local.env
.env.local
.[target-name].env
.[target-name].[target-configuration-name].env
.env.[target-name]
.env.[target-name].[target-configuration-name]
apps/my-app/.env
apps/my-app/.local.env
apps/my-app/.env.local
apps/my-app/.[target-name].env
apps/my-app/.[target-name].[target-configuration-name].env
apps/my-app/.env.[target-name]
apps/my-app/.env.[target-name].[target-configuration-name]
Motivation
We often want to run a task that has multiple configurations with the ability for each configuration to have its own envFile.
For example, you may have multiple configurations (Testing, Staging, Production) for
run-app
. We want each configuration to use a different env file so they use and point at different URLs. We are currently unable to do this. To acheive something similar, we have to either:run-app-in-testing
,run-app-in-staging
etc.If envFiles with both the target and configuration name were automatically picked up and parsed. It would solve a few issues around unnecessarily having multiple targets when configurations should be used or the need to transform env files.
It looks like this idea has been raised within other issues/ feat requests but not implemented:
Suggested Implementation
A change to
getDotenvVariablesForTask()
inpackages/nx/src/tasks-runner/forked-process-task-runner.ts
to include the above search patterns. This would allow the configuration name to be used automatically in all executables.Alternate Implementations
Another alternative is for Nx packages to extend their
options
to allow an env file path.Please do shout though if I have missed something and there is a better alternative than making a change to the task runner process, I'm not familiar with the Nx code base.
The text was updated successfully, but these errors were encountered: