Extension attempts to modify system-wide ZLS settings

[mtlynch]

When the Zig extension prompts me to install ZLS, if I say yes, it attempts to write to ~/.confg/Code/user/settings.json, which is the system-wide config file for VS Code.

On my system, this doesn't work because I manage my home directory with Home Manager, so the settings.json file is read-only.

Repro steps

1. Make ~/.confg/Code/user/settings.jsonread-only
2. Open VS Code in an empty directory
3. Install ZIg VS Code extension
4. From command pallette, choose "Zig Setup: Install Zig"
5. Choose latest version of Zig
6. When prompted, choose to install ZLS

Expected behavior

Extension installs ZLS successfully and enables it within VS Code.

I'd prefer that it write to the project-local .vscode/settings.json rather than the system-wide version, but failing that, I'd like it to at least fail over to the project-local settings one when it can't write the system-wide settings.json.

Actual behavior

Installation fails with this message:

Failed to install Zig 0.14.0-dev.3220: Unable to write into user settings because the file has unsaved changes. Please save the user settings file first and then try again.

Workaround

Add this line to .vscode/settings.json in the local project:

"zig.zls.enabled": "on"

Then reload VS Code.

Environment

• OS: NixOS 24.11 (Linux 6.12.12)
• VS Code: 1.97.0
• Zig VS Code Extension: 0.6.4
• Architecture: AMD64

[alexrp]

I'd prefer that it write to the project-local .vscode/settings.json rather than the system-wide version

In some projects, I have .vscode/settings.json tracked in Git because it contains some very useful project-specific settings that everyone working on it will need. So I really don't like when extensions write to it unnecessarily.

Having said that, the reason zig.path and zig.zls.path have the machine-overridable scope is precisely so that their values don't get synced between machines, allowing the extension to write the system-specific paths without portability worries. This is, AFAIK, the norm for storing paths to external programs in VS Code settings. Ultimately it's up to @Vexu what to do about this, but IMHO, Home Manager is throwing an unnecessary wrench into a scheme that otherwise works just fine.

[Techatrix]

As may be evident from the mentioned workaround, the config option that the extension attempts to modify is zig.zls.enabled. I don’t think saving this in the global/user settings is a bad choice, as it is not project-specific. It seems unlikely that a significant number of users would want their LSP enabled only for certain projects.

In my investigation I have observed the extension to produce the following behavior:

This is what I got after I chose to let the extension install ZLS for me while having a read-only user settings.json which has been created by home-manager. In my opinion, the automatically opened tab combined with the error message should be enough to let the user know that they will need to make this change themselves through their home-manager config if they want this setting to be applied permanently. @mtlynch Did you observe the same behavior about the opened settings.json file with unsaved changes?

Here are some things I have experimented with to try to resolve this issue:

• fall back to project-local settings when it fails to edit the global/user settings. This does not prevent the user settings.json file from being opened like in the picture above. This could be worked around but that may cause problems on its own.
• update the "install ZLS" popup to include a "Yes (workspace only)" option (see picture below). This is just hoping that the user select the right option while unnecessarily complicating this popup.

I think it might be best to not try to workaround this issue in the extension and instead let the user deal with the provided error message and settings file.

Based on my personal experience, I've tried to use home-manager to manage my VS Code settings but switch away from it because I often had various extensions and VS Code itself try to edit the user settings.json file. I'm still using home-manager for various other programs but VS Code has not given me a good experience with it.

[mtlynch]

@mtlynch Did you observe the same behavior about the opened settings.json file with unsaved changes?

Yes, that's the same thing I observe.

The more intuitive behavior to me would be if the extension checks to see if the system-wide settings.json is read-only and fails over to saving it in the workspace settings file if it can't write to the system-wide file.

It's unexpected to me that the extension tries to write to a file that it can see is read-only and then just leaves the user to figure out what to do with this modified file they can't save.

That said, I totally get it if the Home Manager situation is too niche, and this is just a wontfix.

[Techatrix]

The more intuitive behavior to me would be if the extension checks to see if the system-wide settings.json is read-only and fails over to saving it in the workspace settings file if it can't write to the system-wide file.

VS Code extensions do not directly access any settings.json files but instead rely on the VS Code API to read and modify settings, abstracting away the exact state of said files. This means that we would need to somehow figure out where the user settings.json file is located without any help from the VS Code API. This is additional complexity and a potential source of more bugs. If VS Code would provide an easy way to query whether the user settings are modifiable then perhaps there could be some special check for this situation.

Furthermore, updating the workspace settings instead would mean that this popup will appear every time a new workspace is opened, which would be pretty annoying. And what should happen when there is no workspace opened?

It's unexpected to me that the extension tries to write to a file that it can see is read-only and then just leaves the user to figure out what to do with this modified file they can't save.

This isn't specific about the Zig VS Code extension. Even VS Code itself behaves the same when using the "Preferences: Color Theme" command for example.

That said, I totally get it if the Home Manager situation is too niche, and this is just a wontfix.

To clarify, I’m not trying to argue that the home-manager use case shouldn’t be handled, but rather that the current behavior is the best available option for now. The best course of action is for the user to update their settings.json file themselves, as they have explicitly prevented the extension from doing so, which the error message is attempting to convey.

[mtlynch]

To clarify, I’m not trying to argue that the home-manager use case shouldn’t be handled, but rather that the current behavior is the best available option for now. The best course of action is for the user to update their settings.json file themselves, as they have explicitly prevented the extension from doing so, which the error message is attempting to convey.

Yeah, that sounds reasonable to me. I didn't realize that VS Code extensions can't find out whether the settings file is writable.