Feature Request
I'm attempting to use { "path": "${env:APPDATA}/Code/User" } in my workspace to be able to easily open settings.json and keybindings.json as raw files (the custom panels take up too much space and I rarely need them) and it appears variables are not substituted when loading the workspace file.
VS Code version: Code 1.20.1 (f88bbf9137d24d36d968ea6b2911786bfe103002, 2018-02-13T15:34:36.336Z)
OS version: Windows_NT x64 10.0.16299
Related: It's also very hard or impossible to ignore files in a specific folder from the workspace settings. Consider the following scenario:
I have a directory structure
root/
engine/
game/
log/
<various log files>
I configure a multi-root workspace that encompasses both the engine and the game. When I'm working solely on the game I want to see the log files. When I'm working on the engine I want to see the game, but I don't want to see the log files.
I've tried various patterns in settings.files.exclude in the workspace file and I can't find a way to get it to apply only to the game folder.
"game/log": true,
"../game/log": true,
"${workspaceFolder:game}/log": true,
I thought I was doing it wrong.
I've also been frustrated with the settings panels, which might be useful, although extensions are not sorted, and the resizer between the panels is too thin and hard to find, and panels wont resize enough, and search right panel should be separate, but aside from that, $appdata and $username are sometimes helpful with multiple users.
Workarounds...
1) Junctions, C:\cod => %appdata%\Code\
2) Move everything to one path, C:\cod
Maybe this example will help escalate:
Files:
C:\Users\FOO\TheAnswer\42.txt
C:\Users\BAR\TheAnswer\muhuhuh.txt
C:\Users\BAR\Desktop\nothingtoseehere.code-workspace.lnk
Workspace:
C:\nothingtoseehere.code-workspace
Workspace contains:
{ "folders": [
{ "path": "C:\\Users\\BAR\\TheAnswer" },
{ "path": "C:\\Users\\${UserName}\\TheAnswer" }
] }
Problem
You are Bar. Foo wanted to share. Foo's last words were his password. doh.
Warning: Recreation may involve Vogons.
@bpasero, here is a more realistic situation. You are part of a team, and you would like to share the workspace as a part of the GIT repository. Here is an example situation:
{
"folders": [
{
"name": "React Application",
"path": "."
},
{
"name": "GO Server",
"path": "../goserver"
},
{
"name": "Database Models",
"path": "../models-go"
},
{
"name": "GoLang Utilities",
"path": "../utils-go"
},
{
"path": "${env:HOME}/.go/src/example.com/example/models-go",
"name": "Models (testing)"
}
],
"settings": {
"git.ignoreLimitWarning": true
}
}
Right now, the ${env:HOME} does not work, and I would love to see this actually work.
Another use case: I am developing an app which writes to files in the user's home directory ~/myapp/cache/.... Thus I want to watch this cache folder via the workspace path.
{
"name": "cache",
"path": "${env:USERPROFILE}\\.powowshell\\cache"
}
Neither does:
{
"name": "cache",
"path": "~/.powowshell/cache"
}
@bpasero Any milestones for this feature request?
I am also having trouble creating a template workspace for our company dev team, and I currently don't have any workarounds.
For example, in our case given envioronment variable points to a disk where we have our common (company guidelines) folder structure and folders I would like to add to template workspace.
People on this thread might also be interested in upvoting https://github.com/microsoft/vscode/issues/87889 where I am proposing support for repo (folder) environment variables for use in launch configs, tasks, the integrated terminal and anything else related to that repo/folder ....
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!
: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!
@bpasero As this is one of the most "blocking" basic features... I am thinking of investing my time into a fix for this issue. It seems that at least expanding process environment variables would cover a lot of use cases. Has this issue completely fall off the radar?
Any plans, recommendations?
I can currently not provide the time to be a mentor of this feature through a PR, sorry. I would search for issues labeled "help wanted" to make sure you get team members that are willing to review the change.
Since this issue is on the "Backlog" it may be considered in the future, but our "Backlog" is also very large.
Most helpful comment
: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!