Adding envFile argument in nx serve / build for custom env loading

[amal-chandran]

Description

https://nx.dev/l/r/guides/environment-variables#pointing-to-custom-env-files
As per the documentation part above if I need to load custom env files for nx serve i need to use env-cmd -f .qa.env nx serve.
When running it as a single command was ok. But mostly that's not the case we have more than 1 app to serve for development thus use nx run-many --target=serve --all --parallel --maxParallel=10. In that case, we cannot use the custom envs.
For @nrwl/workspace:run-commands has an argument like envFile if we can pass similarly as part of configuration then the whole process will get simplified.

Motivation

We are using different envs for different environments like .env.development for local, .env.staging for staging, and likewise. For next projects(https://nx.dev/l/r/next/overview), these files are working but not for react projects(https://nx.dev/l/r/react/overview). So currently we need to manually copy and paste .env.development to .env. Currently we are using a make file to do the work but if we have it in workspace.json -> app -> configurations then we don't need to depend on the make file

Suggested Implementation

Add an additional argument envFile for react serve command (https://nx.dev/l/r/web/dev-server) and all the other app generators like nest, next, node, etc.

Alternate Implementations

No alternative I could think of or we can only do hacks to solve the issue

[danr-za]

I think also grabbing the .env file by the passed configuration makes total sense.
For example, nx build/server app --prod would grab .env.production while nx build/serve app would grab .env.development.
Btw, this correlates with how environment.ts files are being replaced during the build.

That way we can manage custom configurations (which is usually typical for dev/staging/prod etc.) and add.env files accordingly.

[ShadabFaiz]

Any Update on this ?
This is how I'm currently loading the env for my application:
For QA: npx env-cmd -f apps/<app-name>/.env.qa nx run <app-name>:build:qa,
For staging: npx env-cmd -f apps/<app-name>/.env.staging nx run <app-name>:build:staging,

[idobleicher]

I am having the same issue.

[bojanbass]

+1 for this

[nodegin]

Can't believe other executor doesn't support this

[wesleygrimes]

+1 for this @FrozenPandaz from the Jane tech crew and iheartjane.com. We would be happy to put a PR together if that would help.

We also use the cascade loading method, so we may have a local .env.development.local that we would load in addition to the .env.development. To do this we use the dotenv-cli command: https://www.npmjs.com/package/dotenv-cli which loads them cascadingly.

Our package.json build script looks similar to this:

{
   "build": "dotenv -c development -- nx run-many --target=build --all --parallel=3",
}

It would be lovely if we could add an env specific configuration to the project.json for each build target and provide envFile or envFiles that can be loaded.

"configurations": {
        "development": {
          "envFiles": [
            ".env.development",
            ".env.development.local"
          ]
        },

Then we can update our package.json to have something like:

{
   "build": "nx run-many --target=build --all --parallel=3 --configuration=development",
}

[jscastanos]

@ShadabFaiz +1 it works

[Crocsx]

I would love to have what @wesleygrimes propose !

[dariusj18]

Here's an example of laravel's artisan command and it's syntax is --env=dev loads .env.dev

https://laravel.com/docs/9.x/configuration#additional-environment-files

This is a very very helpful feature for development, especially if you need to target multiple environments and you don't want to pollute your codebase with that kind of configuration.

[aelsaman]

+1

[oojikoo]

+1

[JotaRaffalli]

+1

[codynova]

This is an absolutely vital feature in my opinion. Without the ability to configure .env files in each Nx target's configuration object, it's almost impossible to develop a shared set of build target names across a monorepo. @wesleygrimes suggestion of cascading loading for .env files offers flexibility and would mirror the behavior of tools like NextJS.

[kaifresh]

+1

[zettlrobert]

+1 in support of @wesleygrimes suggestion

[wesleygrimes]

Glad everyone seems to agree, any thoughts or plans to implement something like this @FrozenPandaz?

[wyardley]

Is there any way to ignore .env entirely, or does nx automagically load .env no matter what? Somewhat relevant here, since I assume setting the custom file to a non-existent file or to /dev/null might work to suppress this behavior?

(context: lerna/lerna#3371)

[tschaffter]

@wyardley I bumped into the same issue. Nx attempts to load all the files listed here. One solution seems to get rid of .env and use exclusively .[target-name].env, for example.

[wyardley]

@tschaffter luckily, they were kind enough to (very quickly!) add an option to disable this in #12602! Some more context in the thread mentioned earlier.

[tschaffter]

Thanks for letting me know @wyardley ! The fix is now part of Nx v14.8.6.

[igor-q-bio]

Is there a plan to support .env.CONFIGURATION instead of or in addition to .env.TARGET?

[the-ult]

Was following the guides:

• https://nx.dev/recipes/environment-variables/use-environment-variables-in-angular
• https://nx.dev/recipes/environment-variables/define-environment-variables

And running into the same problem.

Use Case:

• Locally I wish to run/test both with a 'normal' setup -> calling backend etc.
• Mock -> using mock files etc -> different API, MOCK=true and more settings.

I configured: .env.development and .env.mock. And would like to be able to
give the .env.mock as argument or something.
Maybe something like:

 nx serve movie-db --envFile=mock  // OR .env.mock

How can we accomplish this without doing something like this?

 "serve": {
    "executor": "@nrwl/angular:webpack-dev-server",
    "configurations": {
      "production": {
        "browserTarget": "movie-db:build:production"
      },
      "development": {
        "browserTarget": "movie-db:build:development"
      }
    },
    "defaultConfiguration": "development"
  },
  /// THIS IS/FEELS PRETTY REDUNDANT
  "mock": {
    "executor": "@nrwl/angular:webpack-dev-server",
    "configurations": {
      "mock": {
        "browserTarget": "movie-db:build:development"
      }
    },
    "defaultConfiguration": "mock"
  },

 nx run movie-db:mock

Would really prefer something like this:

 "serve": {
    "executor": "@nrwl/angular:webpack-dev-server",
    "configurations": {
      "production": {
        "browserTarget": "movie-db:build:production"
      },
      "development": {
        "browserTarget": "movie-db:build:development"
      },
      "mock": { // ADD extra target.. or even better -> envFile argument
        "browserTarget": "movie-db:build:development"
      }
    },
    "defaultConfiguration": "development"
  },

 nx run movie-db:serve:mock

And a .env.mock environment file.

[kart2190]

Was there an update on this? This is especially relevent when using NextAuth in multiple apps in NX. NEXTAUTH_URL is different for each app and loading them at runtime for different configurations (dev/stg/prod) would be super helpful

[azinod]

+1 looking for this functionality too

@wesleygrimes suggestion seems suitable

[JesseZomer]

Also looking for a solution to this. Can we in the meantime use the solution posted here? Where we just swap the .env file when using a certain configuration.

[nodegin]

For anyone still having issue with this:
(only tested with latest @nrwl/vite builder which works fine for me)
#13288 (comment)

[Hywie]

For anyone looking to use different env files per configuration. A new feat has recently been merged to allow this (#14998)

[AgentEnder]

I'm going to close this out. I think the configuration based env files should hit 98% of the use cases, since you'd be specifying the custom env file within a configuration either way. If anyone has use cases which are not covered by #14998, or has issues after the release of 15.8.0 on this matter, feel free to open a new issue.

[dariusj18]

So to be clear, if I want to run nx serve api and ensure that it loads the .env.dev file or the env.staging file, what would those commands look like?

[AgentEnder]

You would have a configuration for dev / staging defined in the serve target, and run nx serve api -c dev or nx run api:serve:dev

[bojanbass]

You would have a configuration for dev / staging defined in the serve target, and run nx serve api -c dev or nx run api:serve:dev

Not exactly true, as in this case you would need to define .env.serve.dev and .env.serve.staging files, defining only .env.dev doesn't load. I was searching exactly for this one, so I'm wondering if this feature can be included in the core?

I'm currently solving a problem defining different whitelabel variables, and this can quickly become unreadable (imagine 5 whitelabels, each having to define build, serve and build-docker targets). So a workaround could be wrapping those executors (NextJs specific) into custom executors, where based on a schema value (whitelabel value), an ENV variable is set dynamically.

[github-actions]

This issue has been closed for more than 30 days. If this issue is still occuring, please open a new issue with more recent context.