Vscode: Workspace-level environment variable *definitions*

[markm77]

Often I find myself wanting to associate a workspace with an environment variable (e.g. server domain name, development/production tag) but do not want to create a global system environment variable or pollute ~/.bash_profile with such a variable. I would like such an environment variable to be associated only with the workspace "namespace" and be used for tasks, launch configs and integrated terminals started in that workspace.

I would like to suggest adding an env section to the .code-workspace file format similar to that shown below. It is crucial that a .env file argument be supported to allow environment variables to be excluded from source control (e.g. non-source controlled variables could be placed in .env file which is specified in .gitignore).

Then different "flavours" of the same workspace (each using different clones of the same repos) could be used on the same computer - great for side-by-side comparison debugging or temporarily experimenting with a different setup etc.

{
    "folders": [
        {
            "name": "Api",
            "path": ".."
        },
        {
            "name": "Processing",
            "path": "../../client/Processing"
        }
    ],
    "env": {
        "NODE_ENV": "development",
        "DOMAIN": "backend.example.com"
    },
    "launch": {
        "configurations": [],
        "compounds": [
            {
                "name": "Api + Ws",
                "configurations": [
                    "Api",
                    "Ws",
                ]
            }
        ]
    }
}

[markm77]

An extra note. It would be really nice if env could be supported at both workspace and folder levels. This would allow to configure environment at both workspace and folder levels directly or through .gitignore-able env files. This would open up possibilities including multiple clones of the same repo in the same workspace that run with different environment etc. Would be great for comparing and debugging!

Many thanks for considering this feature which I think would greatly enhance VS Code. 😀

NB: note workspace- and folder-level environment is hopefully not just for launch configs but also tasks and terminals.... removing the need for global environment settings....

[aploskov]

Another workaround:

"terminal.integrated.env.linux": {
    "CARGO_HOME": "${env:HOME}/dev/sdk/cargo",
    "RUSTUP_HOME": "${env:HOME}/dev/sdk/rustup",
    "PATH": "${env:HOME}/dev/sdk/cargo/bin:${env:PATH}"
}

This config works good in integrated terminal, but cannot be used by rls-vscode: rust-lang/rls-vscode#721

[markm77]

An extra note. It would be really nice if env could be supported at both workspace and folder levels. This would allow to configure environment at both workspace and folder levels directly or through .gitignore-able env files. This would open up possibilities including multiple clones of the same repo _in the same workspace_ that run with different environment etc. Would be great for comparing and debugging!

Many thanks for considering this feature which I think would greatly enhance VS Code. 😀

NB: note workspace- and folder-level environment is hopefully not just for launch configs but also tasks and terminals.... removing the need for global environment settings....

FYI I have edited the above comment to remove suggestion of putting folder-level environment in .code-workspace as, now having many repos in my workspace, I am really hoping VS Code will embrace repo auto-detection (https://github.com/microsoft/vscode/issues/87888) to reduce the high maintenance associated with a .code-workspace when constantly adding and removing workspace repos.

I will open a new feature request for folder-level environment which could be provided e.g. in .vs-code/env.json. This feature request still stands though as global environment per workspace would be such a useful feature.

[vscodebot[bot]]

This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[vscodebot[bot]]

:slightly_smiling_face: This feature request received a sufficient number of community upvotes and we moved it to our backlog. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[beltaurus]

I found this while I was looking to answer a similar request;
I am assuming that these "workspace environment variables" would be visible to the extensions (which is what I was after):
I have a few applications, which are configured through environment variables. I don't want to introduce those environment variables in my shell where I invoke code.

They should be part of a code workspace, which makes for a self-contained debug environment.

Right now, I need to update environment variables for each extension that I'm using (e.g. Perl and Perl Critic/lint), and then there are extensions that don't let me set those environment variables (e.g. Perl Critic/syntax check).

Setting the variables ONCE, in the workspace settings, and export them to all the extensions would be absolutely wonderful...

[markm77]

@beltaurus Thanks for your comment. My proposal is these variables be not global but "associated only with the workspace namespace and be used for tasks, launch configs and integrated terminals started in that workspace." They might for instance point to a server or give an API version etc. i agree with making them visible to extensions also.

I am basically hoping for namespaced environment variables that are available in the same places as global environment variables when within a workspace "namespace" (i.e. when a VS Code window is opened by a code-workspace file).