-
Notifications
You must be signed in to change notification settings - Fork 30.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Revisit VS Code folder structure for app data, settings, extensions #3884
Comments
I wonder if we should do this before GA. Besides the summary, I also do not like that we have 2 folders, one for application data and one for extensions. Ideally we have one folder for both. |
It was a little confusing when I was writing my script that automates my config to discover there were 2 config folders. If this is going to be done I vote for |
I am more worried about the migration than finding a name :) |
I also don't get why there are two folders. Afaik I also like |
While fiddling with the config directories it might be worth tackling a portable version at the same time #329 |
Not for GA. |
Btw the largest chunk of stuff in app date is created by Chrome itself and is used for local storage, index db, etc. It would be easy to migrate and move our settings out of that folder, I am worried about migrating the rest... |
@bpasero what are your thoughts on getting this in for April? My experience with playing around with user data to date is that it seems fairly contained and can be moved without any issues. The reason I want to do this soon is I'd like to have a set root user data dir as one is required to run under
We could have
For migration something like this should work in
|
Permanently move the user data to a sub-folder of the config directory for the current variant of code. For example: - ~/.config/Code -> ~/.vscode/user-data - ~/.config/Code\ -\ OSS -> ~/.vscode-oss/user-data - ~/.config/Code-Development -> ~/.vscode-oss-dev/user-data Fixes #3884
@Tyriar happy to accept a PR on such a change and migration. |
@Tyriar ah nice, did not see your PR until now! |
Given my feedback, I am not suggesting to do this so late in the milestone. |
@wc7086 Please stop writing comments like that — this does not provide any value to solve the problem, and all the people subscribed to the topic need to get notification about that. |
@TomaszGasior What do you suggest people should do to increase the chances that this will be fixed? |
True. |
Anyways bumping won`t get the issue resolved faster. I would like to get notifications about the progress, not about amount of people who discover it. I guess I will unsubscribe from this issue because github zoomers don't understand what tickets are. |
@ZerdoX-x, you can subscribe to whether the issue is closed or reopened rather than unsubscribe entirely. |
Currently, VSCode alone stores a total of 1.6 GiB of just cache data in my roaming profile, making the morning login over my slow DSL connection extremely time-consuming.
MS Teams stores another 1.76 GiB, and Slack another 742 MiB (but at least that one has an excuse, it's not a Microsoft product). From an old Microsoft Technet Managing Roaming User Data Deployment Guide:
4 GiB of cache data is too much to sync at every login. |
I created a separate issue about cache data #191434 but it's closed as a duplicate of this, so duplicating here my list of directories with cache data on Linux systems, that should be moved to
|
Also, want to point to the more general Electron bug about using configuration folders as cache folders: electron/electron#8124 |
@Tyriar On Linux i.e. Would be nice to update the OP with the current paths, easy to test via: mkdir -p "${HOME}/testdir"; export XDG_CONFIG_HOME="${HOME}/testdir"; code |
@C0rn3j Note that one of the points of this folder structure problems is that Some things should actually go into |
Stuff like |
560 Upvotes. 30 or so separate linked issues. Perhaps this issue should be split up into several smaller tasks that can be worked on separately.
Creating dedicated tickets for each of the items above would help reduce noise, make the tasks feel more manageable (increasing motivation), and help encourage community participation. This is just my 2 cents. |
Any chance this could have someone working on it? |
I was hoping to take a stab at it but getting the local dev env working was too much of a hassle @thepkc |
As a Mac user, I would like to underline that the Since this is a big change, and we are likely not getting another chance at fixing it, I think it's important to get it right. Reading this discussion (and the current outline in the top post), I get the impression that you would like to clean From a Mac user perspective: I am convinced that you would find that most engineers reaching this thread are here because they want to be able to manage their setup on their own terms. We want to be able to source control our dotfiles, and we do that the same way that the Linux folk do it (e.g. using GNU Stow). So while Apple does have guidelines for where to store which pieces of data, that does not need to be the end all be all. It's just a recommendation, just like Take this code, for example: vscode/src/vs/platform/environment/node/userDataPath.js Lines 98 to 103 in 1fd17c5
Please, do use Apple's recommended standard path as a default, but allow us to set the same freedom as you would Linux, like this: case 'darwin':
- appDataPath = path.join(os.homedir(), 'Library', 'Application Support');
+ appDataPath = process.env['XDG_CONFIG_HOME'] || path.join(os.homedir(), 'Library', 'Application Support');
break;
case 'linux':
appDataPath = process.env['XDG_CONFIG_HOME'] || path.join(os.homedir(), '.config');
break; If there is proper separation between cache, data and config, I would not expect the Linux and Darwin setup to differ all that much, so if you got it working on Linux, synching the |
Please be aware that many of us on Linux and perhaps macOS are still waiting for this to be addressed. I totally agree with the content from #3884 (comment). This is not about Many apps are now adherent to the XDG standard as published at XDG Base Directory Specification.
And please DO clean up the FYI - (for what it is worth) I prefer
Thanks. |
It's probably the most used IDE, and you guys still haven't made it possible to allow at least developers to change the location of their settings/extensions/keybindings/etc. This should be as simple as:
or something to that effect. I mean, I use neovim but for the occasional IDE need, I would use VSC, Zed, etc, so why not let people control where they configure things? |
Since this seems to get lost every once in a while: there is no way to set persistent environment variables for a user1 on macOS. The closest is to set up a deamon to run In order to be effective for macOS users, the solution needs to work without environment variables. One option would be to check the filesystem for XDG-compatible paths, as I outlined at: #162712 But I think many of us on macOS would also be sufficiently happy if VS Code just placed its files in appropriate folders under And I think we'd be the most glad if the VS Code team would be willing to commit to any given solution. I think many of us would be eager to send a PR if we know it will move the issue forward instead of just leading to further discussion. This issue is on the first page of the most upvoted issues and is a way to make a lot of users happier with a relatively small code change. Footnotes
|
This comment has been minimized.
This comment has been minimized.
With all due respect, this is misinformation.
(You might note that I already covered this in the comment you are replying to.) I know this because I have a daemon configured exactly like this. I just performed a reboot to double-check if maybe it was more reliable now. But no, the env vars set in this way were not available in apps that relaunched as part of the reboot login. (I'd love to be proven wrong if I'm missing something. You can see my configuration here. But even if this does work, 1) Apple's official docs on this do not specify a way to ensure a daemon is started before any apps are launched1, 2) Apple has changed this kind of stuff without notice and may break it again at any time, and 3) compared to proper macOS settings, this is not beginner-friendly and very unsatisfying compared to normal dotfile management.) Believe me, I'd love not to have to worry about these fussy details and just pick the first practical and safe thing that works. I'd even re-enable my code to set But I'm still not aware of a way. 😔 Footnotes
|
I think I was a bit unnecessarily salty in my last comment, but I guess there are some things that are not common knowledge. Here is an explicit demonstration of why environment variables are not sufficient for macOS users, at least using the widely cited daemon approach.
# Open VS Code (so it relaunches automatically when logging in after reboot, at least with default macOS settings)
open -a "Visual Studio Code"
mkdir -p ~/vscode-env-var-test
cat << EOF > ${HOME}/Library/LaunchAgents/vscode-env-var-test.plist
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0"><dict>
<key>Label</key>
<string>com.example.vscode-env-var-test</string>
<key>ProgramArguments</key>
<array>
<string>/bin/bash</string>
<string>-c</string>
<string>date > ${HOME}/vscode-env-var-test/date.txt && launchctl setenv VSCODE_EXTENSIONS ${HOME}/vscode-env-var-test/extensions</string>
</array>
<key>RunAtLoad</key>
<true/>
</dict>
</plist>
EOF
# Reboot (with sudo prompt)
sudo reboot now
Note that this is a significantly worse user experience, because you have two extension folders and VS Code sometimes uses one and sometimes the other. I can imagine someone getting very confused why their extension installations sometimes don't persist, or that they're suddenly running extensions they thought they had uninstalled. Or that they're running a different version of an extension than they thought they had configured. Depending on the extensions, this can result in mangled code or a broken VS Code setup. This demonstrates that a solution without environment variables is needed for macOS users. P.S. Clean up the test code using: rm -f ${HOME}/Library/LaunchAgents/vscode-env-var-test.plist
rm -rf ${HOME}/vscode-env-var-test/
launchctl unsetenv VSCODE_EXTENSIONS
# Close and reopen VS Code to restore the normal extensions folder
osascript -e 'tell application "Visual Studio Code" to quit'
open -a "Visual Studio Code" |
Whether I'm using Mac or Linux I habitually launch code from the terminal, so my environment variables are always loaded because the shell loads them :) |
The workaround for the daemon's unpredictable startup timing is to kill (and relaunch) all apps used to launch other executables after all In my setup, I restart the following: Finder, Dock, Raycast, iTerm, etc. Any app launched by these will see the "global" variables. |
Config is stored in
~/.config/Code[ - <quality>]/User
. To match platform conventions (lowercase and hyphens for everything) as well as to keep consistency with the clicode[-<quality>]
I propose we change the settings directory one of:~/.config/code[-<quality>]/user
~/.vscode[-<quality>]
(see Why are settings and keybindings not in the same directory as extensions? #3883)~/.code[-<quality>]
(to prevent using 'vs' showing up in the OSS build as it is now)If we moved this it would probably require some discovery/migration on first launch of a newer version.
The below is a living document.
Proposed folder structure
Notes:
code
vsvscode
thing in this change; only official builds should carry the visual studio branding, that should carry over to the config directories consistently as well.--user-data-dir
and--extensions-dir
will need to be adjusted for this, something like--config-dir
and--cache-dir
would probably be better.Windows
Old
New
Notes:
%APPDATA%
is roaming and%LOCALAPPDATA%
is local, meaning extensions will not be carried across multiple machines until a solution is devised for Persist an extensions manifest file #15442. An extension manifest, eg.%APPDATA%\Microsoft\[Visual Studio ]Code[ - Variant]\extensions.json
which automatically installs extensions is my thinking of solving this problem.Linux
Old
New
Notes:
$XDG_CACHE_HOME
would be best for extensions provided there is an extensions manifest in$XDG_CONFIG_HOME
Persist an extensions manifest file #15442.$XDG_DATA_HOME
?Mac
Old
New
Notes:
The text was updated successfully, but these errors were encountered: