Workspace-level environment variable *definitions*

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",
				]
			}
		]
	}
}

[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]]

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