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/vscode-rust#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 (#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]

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]

🙂 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!

[dseynhae]

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).

[huntc]

I'm also looking for this feature. Ideally, I'd like to be able to declare environment variables within my workspace folder, but also permit those that are declared there to be overwritten by a .env file present on my file system. This .env file would not be saved with my project/workspace, but optionally declared by each developer using the project.

My specific use-case is for C/C++ tooling, where I need to declare an SDK_ROOT env and a GNU_INSTALL_ROOT env. There is no default location for these variables as each developer will locate them on their file system as they wish. Having the workspace declare them with, say, null values could then lead to VS Code hinting that a .env file is required with their assignment on loading the workspace/project.

[corker]

I'm a maintainer of corker.vscode-micromamba extension. This extension aims to allow VSCode IDE users to configure dev environments automatically by utilizing micromamba - an alternative for conda built with C++. E.g., when a developer wants to create a nodejs project, the extension could automatically install nodejs in a virtual environment from conda-forge using micromamba. Virtual environments, in fact, are just a set of environment variables, including modified PATH. It's possible to configure terminal environment variables when a virtual environment is created. This is what python extension is doing when activating a virtual environment. But in the case of vscode-micromamba other extensions, like jest, or go-extension need to know about these modified environment variables, which is not possible. Some extensions, like python extension, can handle DotEnv files, and this way, they could be configured to work, but many are not. Adding a possibility to tell a workspace to use a DotEnv file via settings would be a great possibility to make vscode-micromamba integrate nicely with any extension out of the box.

[ekaradzha-qb]

This is very needed feature with multi-workspace project as well. Defining variables would make easier adapting the project configuration for cross-platform usage and conditional compilation with C++;

[lalomartins]

Here's another use case in case that helps: I have one project here that needs a different version of Java than everything else on the machine. So to develop on that one I need to make a shell script that sets JAVA_HOME to the right value, then launches vscode with that environment. And remember not to run multiple windows in that state.

[eleksir]

I've got the same situation as @dseynhae - multiple perl workspaces, each with its own vendored libs dir and PERL5LIB should point to correct dir in each project.