~/.local/share/code-server/User/settings.json is not respected in code-server v4.0.0

[benz0li]

OS/Web Information

• Web Browser: Firefox 95.0 (64-bit)
• Local OS: macOS 10.14.6 (Mojave)
• Remote OS: Debian bullseye
• Remote Architecture: 64-bit
• code-server --version: 4.0.0 0f39595

Steps to Reproduce

Log in at https://vscode-r.jupyter.b-data.ch.

Expected

The following settings should be applied:

~/.local/share/code-server/User/settings.json

{
  "editor.tabSize": 2,
  "telemetry.enableTelemetry": false,
  "gitlens.advanced.telemetry.enabled": false,
  "r.bracketedPaste": true,
  "r.plot.useHttpgd": true,
  "r.rterm.linux": "/usr/local/bin/radian",
  "r.rterm.option": [],
  "r.workspaceViewer.showObjectSize": true,
  "workbench.colorTheme": "Default Dark+",
  "terminal.integrated.fontFamily": "MesloLGS NF",
  "r.sessionWatcher": true
}

Actual

Settings are not applied.
ℹ️ It seems v4.0.0 is using the browser storage instead of the file system to read/set settings.

Logs

On demand only.
👉 Issue may be reproduced any time by @code-asher, @jsjoeio or @bpmct at https://vscode-r.jupyter.b-data.ch.

Screenshot

None.

Notes

See #2274 for an identical issue with previous versions.

This issue can be reproduced in VS Code: No

[benz0li]

I don't mind that the state is stored in the browser's storage (#4212).

But one should have the possibility to pre-populate ~/.local/share/code-server/User/settings.json with default settings (#2274 (comment)), e.g. when creating a docker image.

[w0otness]

On a similar note, "bind-addr:" in ~/.config/code-server/config.yaml is not respected either.

All other default options are still respected though.

[code-asher]

Might be another patch that was not ported over when we hard reset to upstream's new server. Hopefully I can just apply the old patch and it will work. This is probably why #2306 has cropped up again too.

I think we may want to enforce e2e tests for various patches we make to VS Code since otherwise we tend to lose them when major refactors due to upstream changes like this happen. Individual patch files instead of a fork would also make the changes more obvious which might be worth considering.

[jsjoeio]

Individual patch files instead of a fork would also make the changes more obvious which might be worth considering.

I was thinking about this too. Could we combine the workflows somehow? I.e. keep the fork (so we can submit upstream) and then maintain patches in that repo?

[code-asher]

Could definitely do. One advantage to keeping patches here is that we would not need to make double PRs for every fix.

[jsjoeio]

Let's plan to have a discussion offline in January and then I'll share notes in a Discussion afterwards with the community.