[Preview] Add setting to move .lscache files to $HOME/.cache

[dibarbet]

Originally filed by @StringEpsilon at dotnet/vscode-csharp#9145

Is your feature request related to a problem? Please describe.

I just noticed that the preview-version of the C# Dev Kit extension creates .lscache files in the same folder as the .csproj file it belongs to. A general cache for the LSP seems like a good idea, but I do not like configuring git to ignore temporary and cache files or files that are specific to one tool or another that may not be used by everyone working on a repository.
Locally I also have backup-scripts that I need to tell about files like that.

Describe the solution you would like

The preferred option for be is to enable the cache, but have those files live in ~/.cache/vscode-sharp/... instead of polluting my workspace folders and having to adjust my IDE and git settings. That is what ~/.cache is for, after all, and I assume the same is true for AppData\Local\Temp on windows.

My current solution is to simply disable the cache, but if it helps with performance I'd rather not have to do that.

[drewnoakes]

@StringEpsilon thanks very much for trying the latest builds and providing feedback.

There is a logic behind the current placement:

1. Cache files are designed to be transferrable between machines. If you check them in, then you have faster performance when you clone the repo, and when you switch branches. And if you have agents that work in worktrees that need LSP services, they will get that data much faster than if the agent needs to rebuild all those caches on each worktree. The file format is designed to reduce the chance for merge conflicts.

2. VS Code can open any folder, at any level. It's not always obvious where the "root" folder is. Is it the workspace root? Is it the git repo root? What if you're not using git?

I'm interested in people's thoughts.

[StringEpsilon]

And if you have agents that work in worktrees that need LSP services

I would expect that any tool that is not strictly a necessary part of the project itself (say dotnet or vite) puts it's configuration and cache files in the appropriate places outside the repository confinements. What if there is another language server implementation used by some IDE and LLM integrations that use a different cache format.

If you check them in, then you have faster performance when you clone the repo, and when you switch branches.

What if half the team uses vi and does not update the lscache files in the branches (because they can't) while the rest of the team does use VS Code and does update the cache files. I think most heterogeneous teams would either end up putting the files into .gitignore anyway or ask those using VS Code to put them in their global .gitignore as to not create extra noise in PRS, so the benefit of having the cache files in the project folder is greatly diminished.

2. VS Code can open any folder, at any level. It's not always obvious where the "root" folder is. Is it the workspace root? Is it the git repo root? What if you're not using git?

My request is to put the cachefiles not into the root folder of the project, but into /home/user/.cache/vscode-dotnettools / C:/Users/user/AppData/Local/Temp if the user prefers their cache files and tool-specific configuration not to "litter" their various project folders but also does not want to disable the feature entirely. It's a request for an option, not to change the default :)

[ivanjx]

how much of performance improvement does .lscache bring? if it is not that big, i would rather disable it

[JakeRadMSFT]

70% reduction and soon more.

[ivanjx]

or maybe consider using file extensions that is already available in dotnet new gitignore or use the obj folder

[maddymontaquila]

Can you put it in bin/obj? I dont mind a cold start perf hit but that persists as long as i dont run a clean

[JakeRadMSFT]

I'd suggest you check it in but we're experimenting here. Thanks for trying things out and we hear your feedback!

[jaredpar]

Cache files are designed to be transferrable between machines.

Agree but the issue is around location + quantity. There are a lot of efforts around reducing the number of artifacts in a standard project directory. This seems like it goes backwards a bit on this.

VS Code can open any folder, at any level. It's not always obvious where the "root" folder is. Is it the workspace root? Is it the git repo root? What if you're not using git?

Agree there isn't a 100% silver bullet answer but feel like a series of fall backs will produce expected behavior in most cases. Example: next to solution, then next to .git, current dir, etc ...

[JakeRadMSFT]

Totally some dials we can turn here but we're trying to do the easiest least complex thing first and keep iterating in prerelease here.

Thanks for feedback all -- we'll keep iterating on this.

[JakeRadMSFT]

What if half the team uses vi and does not update the lscache files in the branches (because they can't) while the rest of the team does use VS Code and does update the cache files. I think most heterogeneous teams would either end up putting the files into .gitignore anyway or ask those using VS Code to put them in their global .gitignore as to not create extra noise in PRS, so the benefit of having the cache files in the project folder is greatly diminished.

One of the design principles we have with this is that the caches can be invalid. The next successful build will get them up to date. They don't need to be perfect before checking in.

Again not fully decided but we appreciate you going on this journey with us.

I think it would be good for us to add more to the comments or some sort of "experiment" web view that lets folks know what we're experimenting with vs what is decided and heading to stable.

[DustinCampbell]

In my humble opinion, it'd probably be better to make a decision now about where this cache file should be placed initially. A good design principle to adopt when experimenting in pre-release would be to use defaults that help the user avoid making mistakes. Placed next to the project file, users will definitely make mistakes. I would guess that many users won't even notice the file until they've added it to a commit and unintentionally pushed it to origin. When a user finds that file in their repo, they probably won't be happy about it. Instead, they'll complain that C# DevKit is dropping garbage files in their code.

One of the design principles we have with this is that the caches can be invalid. The next successful build will get them up to date. They don't need to be perfect before checking in.

Another design principle to consider adopting: Users shouldn't be forced to diff or merge C# DevKit's implementation details. If the LS cache file is in source control, there will ultimately be merge conflicts that have to be dealt with. Merging LS cache files is definitely not something the user should be doing! That could result an old, invalid cache file in source control if the discard their local changes, or worse, they could corrupt the cache file in a way we didn't foresee and break caching altogether.

IMO, this file should be placed out of the way initially. Users shouldn't be managing or manipulating it, and it isn't part of their code. If there turns out to be a scenario where the user might want to do check it into source control, we should enable that through a dial now rather than wait for the obvious complaints.

[cYCL157]

One of the design principles we have with this is that the caches can be invalid. The next successful build will get them up to date. They don't need to be perfect before checking in.

if they are rebuilt on next build, i would say that they would be better outside of what would be committed -- either in a users home or temp directory or in bin/obj directories.

I definitely agree that I would not want to have to deal with merge conflicts of those files if they are really build time output files.