Support envfile for tasks.json

[felixfbecker]

The node and Go debuggers both support specifying an env file for environment variables instead of the env hash. It would be great if we could use the same file in tasks.json to have a single source of truth that can also be used by non-vscode scripts

[dbaeumer]

Can you provide me with an example on how this should look like. Why isn't this a normal file

[felixfbecker]

It is just a key/value file:

FOO=hello
BAR=world

It can be used with the Node debugger as envFile: https://code.visualstudio.com/docs/nodejs/nodejs-debugging#_launch-configuration-attributes

And it can be easily read into e.g. a bash script too.

Not sure what you mean with "Why isn't it a normal file"?

[dbaeumer]

Not sure what you mean with "Why isn't it a normal file"?

If it is a simple file what is preventing you from using it in a tasks.json file.

[felixfbecker]

If you mean why am I not copying the settings over, it is to have a single source of truth. It's the same justification why node debugger and the Go debugger added this config option. tasks.json is not understood by other tools and not every dev uses VS Code, but an env file can be read in easily by a shell script.

[dbaeumer]

I am still puzzled with this. All tasks does is calling other programs. Could the task description not simple pass the right argument (the envfile) to the program it starts. Or do you want tasks to have a setting to read envs vars from a file when you do variable substitution like ${env:xxxx}?

[felixfbecker]

A lot of commands that are candidates to be run through the task system are configured through environment variables - which is why the tasks.json env option is great. I can write a tasks.json that has a bunch of tasks that are interconnected with dependsOn and have individual problem matchers and they receive the same env vars.

But not everyone uses VS Code, so you will want to provide a way to run these tasks without VS Code, e.g. from a bash script that runs all these commands and sets the same env vars. You want to avoid fragmenting all these env vars between the tasks.json and the script.

Of course, you could now configure your tasks.json to run just a single bash script instead of all the individual commands. But then you lose the ability to specify a problem matcher per task, run them individually etc.

So it would be great to be able to point tasks.json to an external file that contains env vars as simple key=value lines and have the script also read in that external file to have a single source of truth.

[dbaeumer]

Now I got it.

[felixfbecker]

Another reason for this if your application needs secret environment variables like tokens - you can set them in a .gitignored envfile, but commit the tasks.json

[myrup]

I'm missing the envFile as an option for a .Net Core Launch configuration (for .gitignore reasons). Shouldn't it be available for all configurations and tasks that start processes?

[acdha]

I just ran into this with a Python app. After #14523 the stock debugger configs automatically reuse the configuration that my external (pipenv) tooling uses because they have envFile=.env in the config. It'd be really nice if that was supported in tasks as well.

[felixhayashi]

I agree with @myrup, the .env constants should be equally accessible from within launch.json – not just tasks.json. I saw there was some similar discussion here in https://github.com/Microsoft/vscode/issues/14523 resulting in an envFile property but it doesn't seem to have been implemented...

[petermetz]

Another use-case why this would be great: You want to store the tasks.json file under version control, but not your environment variables which may contain sensitive data. Without the envFile property there is no easy way to separate the two.

[cdarwin]

For the time being I am working around this by adding a prefix to my task command which essentially sources the .env file used by launch.json.

[gost-serb]

Is this issue still actual?

[doomleika]

Would like to have this too, in the mean time. use $(cat .env | xargs) | <your command>

[ekkis]

I support this request. having all my environment variables in a file and being able to run tasks with those values available would be very valuable

[ekkis]

in fact, I'll go further, having the "env" key in options makes no sense at all. it means I have to hard-code all the environment variables I need into a VSCode configuration file?? that's a terrible approach

[adriantorrie]

Need .env file support in tasks.

1. Keeps secrets out of git
2. Define my env vars in one place
3. It is a standard workflow for multiple languages to use .env file

Here is another use case:

• I was hoping to recreate this Makefile (link) in tasks.json to prevent having to install make on Windows
• However I need to pass build args from my .env file (The docker extension for VSCode isn't flexible enough for this approach)
  • Because I cant do the above: I now have to write separate docker-compose.<make step>.yml files in the meantime
  • But: docker-compose doesn't support BuildKit yet, which means I can't bind mount local volumes into the build scope, which would allow me to export unit test results from the images at build time (also don't get the parallel stage builds either)
  • Some of the runtime arguments are secrets (i.e. docker run -e password=$PASSWORD), so there is no way they are being hard-coded into tasks.json
  • So I don't have any means to a fully-functional multi-stage build with build-time bind mounts

The above workflow example in the Makefile will be reused in our CI pipeline.

• Essentially allows our developers to run locally what will be run in the CI pipeline
• This gives us a CI pipeline agnostic approach that prevents vendor lock-in

So the only thing we're missing at the moment is being able to give devs a clean workflow on their local computers.

/s Or we tell them them to maintain both .env and tasks.json themselves and keep them out of git, and that we expect them to do this for the 50+ microservices we have built in the past 8 months, and to keep doing it for the additional ones in the future.

[ekkis]

For the time being I am working around this by adding a prefix to my task command which essentially sources the .env file used by launch.json.

how do you do it? my .env file doesn't include the "export" keyword and thus . .env doesn't work as child processes can't see the variables. I also don't see any parameters to the source command to automatically export

[warnes]

A nice secondary feature would be to include an overwrite:True argument envFile to control whether the settings in the file overwrite existing environment variable values.

[ayoubserti]

Hi is there any progress on this request? I need also to define some .env variables locally to be used by tasks.json

[dellagustin-sap]

This seems to going in a similar direction to #89825

[alexandrulesi]

I'd also be interested in seeing this.

This seems to going in a similar direction to #89825

The solution suggested in the other ticket is to add inputs to tasks.json, but what we are ultimately looking for is a way to run the debugger and only update all environment variables in .env, and not in multiple places.

[mpelnens]

This would be extremely useful in cases where environment variables contain sensitive data like tokens or passwords. With 'envFile' support the .env file could be added to .gitignore

[pcherna]

In light testing, the following seems to be an OK workaround for Linux/Mac. Create a .env file with your local config and secrets, e.g.:

FOO_USERNAME=person@example.com
FOO_PASSWORD=SecretDoNotShare

Then in your tasks.json, where before you had this bad solution:

...
"command": "myfoo person@example.com:SecretDoNotShare ..."
...

you can now say:

...
"command": "export $(xargs < .env) && myfoo $FOO_USERNAME:$FOO_PASSWORD ..."
...

and now tasks.json is separated from your .env config, and can be safely committed to source control.

[zkrising]

Any progress on this? Seems like a fairly necessary feature for tasks.

[joundso]

Aren't they implemented now? --> "envFiles": ["../secret.env"] At least something like this is working in the tasks.json:

{
  "version": "2.0.0",
  "tasks": [
    {
      "type": "docker-build",
      "label": "docker-build",
      "platform": "python",
      "dockerBuild": {
        "tag": "rapid:latest",
        "dockerfile": "${workspaceFolder}/Dockerfile",
        "context": "${workspaceFolder}",
        "pull": true
      }
    },
    {
      "type": "docker-run",
      "label": "docker-run: debug",
      "dependsOn": ["docker-build"],
      "dockerRun": {
        "containerName": "YOUR_IMAGE_NAME",
        "image": "YOUR_IMAGE_NAME:YOUR_IMAGE_TAG",
        "env": {
          "KEY1": "VAL1",
          "KEY2": "VAL2"
        },
        "volumes": [
          {
            "containerPath": "/app/data/out",
            "localPath": "${workspaceFolder}/data/out"
          }
        ],
        "envFiles": ["../secret.env"],
        "ports": [
          {
            "containerPort": 5000,
            "hostPort": 5000
          }
        ]
      },
      "python": {
        "file": "main.py"
      }
    }
  ]
}

This leads to a docker run --env-file "../secret.env" beeing executed.

[fredjeck]

I would also love to have this feature implemented. Currently handling multiple services which are relying on API keys, or certificates passwords which need to be passed to the docker build and debug tasks as env variables. I want to keep those out of Git and I want that each developer has its own local configuration. It would be much cleaner if this configuration can be defined in a local env file rather than having to put those infos into env scoped environment variables

[gustavorps]

+1

[Materie]

Still very much needed for the case where you want to not commit the env var data, but do want to commit the task itself.

I would like to have a task everyone in the team can reuse, then let them tweak the actual URIs where the task would run at by setting the env vars to locations on their machine which would be different for each developer.

[verikono]

5 Years Later.... (joke aside , was hoping this would be a feature by now) - keep up the good work, I love VSCode ;)

[ant1fact]

Please implement this. Currently the alternative is to add a project-specific settings.json that can hold config variables. This is one additional place where variables need to be maintained and they also don't provide any value outside of other vscode specific configuration files.

[tvsbrent]

Another workaround to share, although it would only work in a Linux / Mac environment, which worked fine for me, as I was intending this for a devcontainer.

Anyway, I created the following bash script to set the environment variables in the current context and then run the remaining positional arguments as a command.

#!/usr/bin/env bash

if [[ $# -lt 2 ]]
then
  echo "Usage: $(basename "$0") env_file (additional argument ...)"
  exit 1
fi

# We expect the first argument to be the path to the env file, so set those
# variables in the current shell and slice that argument off.
# shellcheck source=/dev/null
source "$1"
shift

exec "$@"

That allowed me to do this in the tasks.json file.

{
  "tasks": [
    {
      "label": "test",
      "type": "shell",
      "command": "${workspaceFolder}/.devcontainer/run-task.sh",
      "args": [
        "env.tests",
        "/usr/local/python/current/bin/py.test",
        "/src",
        "--tb=line"
      ]
    }
  ]
}

[adriantorrie]

Please implement this. Currently the alternative is to add a project-specific settings.json that can hold config variables. This is one additional place where variables need to be maintained and they also don't provide any value outside of other vscode specific configuration files.

Agree. Every other function in vscode supports a .env file directly.

Please implement support for .env in tasks.json

[adamrybak]

Would love this feature!

[eriktelepovsky]

+1

[PhilippPolterauer]

+1

[erayerdin]

This is very much needed for securing your API keys and gitignoring them. Not only that, the workaround solutions provided here are not working quite well with different types of tasks (e.g. Flutter/Dart).

[Unintendedz]

This feature would be extremely useful, The current workaround solutions are not ideal, either hardcoding sensitive information in the configuration files or using additional scripts to load the environment variables.

Being able to directly reference the .env file in tasks.json would allow us to better manage environment variables, while also keeping sensitive information out of the Git repository. This would greatly improve the UX of VSCode.

[emircanerkul]

+1

Wow, it was 7 years old issue. Actually similar was done for the launch one, didn't get why this is still on stale.

[doomleika]

I suppose this is not going to be done, ever. since I've commented and subb'd this issue 5 years ago. Probably going to find an extension for this...

[LePau]

For the time being I am working around this by adding a prefix to my task command which essentially sources the .env file used by launch.json.

how do you do it? my .env file doesn't include the "export" keyword and thus . .env doesn't work as child processes can't see the variables. I also don't see any parameters to the source command to automatically export

Not OP, but this is my workaround for now.

npm i -g dotenv-cli

Then in tasks.json:

        {
            "label": "build",
            "command": "dotenv",
            "type": "process",
            "args": [
                "-e",
                "${workspaceFolder}/.env",
                "--",
                "dotnet",
                "build",
                "${workspaceFolder}/mySolution.sln",
                "/property:GenerateFullPaths=true",
                "/consoleloggerparameters:NoSummary;ForceNoAlign"
            ],

[mathisgauthey]

I would really benefit from it on launch.json and tasks.json for the reasons stated here.

[lyf2000]

dn why downvoted for @joundso 's comment, but

            "dockerRun": {
                "envFiles": [
                    "${workspaceFolder}/borya.env"
                ]
            }

worked for me, ty

full file .vscode/tasks.json:

{
    "version": "2.0.0",
    "tasks": [
        {
            "type": "docker-build",
            "label": "docker-build",
            "platform": "python",
            "dockerBuild": {
                "tag": "sonya:latest",
                "dockerfile": "${workspaceFolder}/Dockerfile",
                "context": "${workspaceFolder}",
                "pull": true
            }
        },
        {
            "type": "docker-run",
            "label": "docker-run: debug",
            "dependsOn": [
                // "docker-build"
            ],
            "python": {
                "file": "main.py",
            },
            "dockerRun": {
                "envFiles": [
                    "${workspaceFolder}/borya.env"
                ]
            }
        }
    ]
}

[sagarvelankar]

My solution is to change command yarn dev to export $(grep -v -e '^\\s*#' .env | xargs) && yarn dev. Same should work for npm.

{
  "tasks": [
    {
      "command": "export $(grep -v -e '^\\s*#' .env | xargs) && yarn dev",
      "group": {
        "isDefault": true,
        "kind": "build"
      },
      "label": "yarn dev",
      "type": "shell"
    },
    {
      "command": "yarn install",
      "group": {
        "kind": "build"
      },
      "label": "yarn install",
      "type": "shell"
    },
  ],
  "version": "2.0.0"
}

[laverdet]

@sagarvelankar just source the variables:

{
    "version": "2.0.0",
    "options": {
        "env": {
            "ENV_FILE": "${workspaceFolder}/.env",
        },
    },
    "tasks": [
        {
            "label": "yarn dev",
            "type": "shell",
            "command": "set -a; . \"$ENV_FILE\"; yarn dev",
        },
    ],
}

[igiona]

; . \"$ENV_FILE\"

This approach is nice, but would be even better if VsCode would allow to add a "env file" either in options or in the task itself.

[baebranch]

+1. This would be so awesome.

[lex-ibm]

Pretty please?

[lex-ibm]

I mean, it's been 7 years, 4 months and 17 days and people are still asking for this...