userpreferences parsing/ls config handing

[iisaduan]

• userpreferences implemented into server, session, and snapshot/languageService's lifecycles.
• userpreferences parsing implemented-- can take vscode's default typescript.preferences, or a flat json like typescript-language-server

todo:

• javascript
• format
• server settings

[jakebailey]

A full implementation of LSP compliant config getting/updating requires more work in the extension (currently in progress)

What is needed? I would think we would just ask for the setting blocks we are interested in and watch them, from the server side (no extension code needed).

[iisaduan]

Our userPreferences struct doesn't exist at all in vscode--the previous extension did a lot of processing of the way that vscode's settings.json is represented before it passed a userPreferences to tsserver. We could do this processing on our side, but the code is so much more complicated in go (hence why I didn't implement every preference), and would mean that other clients (if they want to support userPreferences) have to convert their preferences into vscode's preferences, which then our server would convert again. Also, LSP spec says that the client should do this processing.

The other extension changes include to make configuration happen on initialization

[jakebailey]

I feel confused. The LSP config spec is exactly the same as asking VS Code for a setting out of JSON. Putting more code in the client is just going to make that same code repeat across editors...

[gabritto]

Don't we also need to register with the client here to be able to actually get config change notifications? Just like we do in WatchFiles.

[iisaduan]

Re: this + the comment above (link), I didn't fully implement this function because I wanted to figure out what we're going to process in the extension first and I wasn't sure the range of how much info that the client can pass to the server (will it always pass the entire new config upon changes? or only the differences?)

[gabritto]

I do think we should move this handling to initialization. Or are going to need to handle other requests as well?

[iisaduan]

I'm not sure what we will need in the future

[andrewbranch]

I think you could imagine the fourslash client handling diagnostics refresh requests and potentially even watch requests.

[iisaduan]

If we're going to port the fourslash/server tests, then those probably will have to be handled?

[Copilot]

Pull Request Overview

This PR implements user preferences support throughout the codebase to unblock future work, focusing on fourslash test capabilities and inlay hints configuration from VS Code. The implementation adds user preferences handling to the session lifecycle, language service, and LSP server with initial support for parsing inlay hints settings from VS Code client configuration.

• Adds user preferences threading through session, snapshot, and language service layers
• Implements VS Code configuration parsing for inlay hints preferences
• Extends fourslash testing framework to support user preferences configuration

Reviewed Changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated 8 comments.

Show a summary per file

File	Description
internal/project/snapshot.go	Adds user preferences field and getter method to snapshot
internal/project/session.go	Implements user preferences configuration and change tracking in session
internal/project/api.go	Updates API calls to include user preferences parameter
internal/lsp/server.go	Adds configuration request handling and inlay hints parsing from VS Code
internal/ls/types.go	Extends UserPreferences with inlay hints fields and copy methods
internal/ls/languageservice.go	Adds user preferences parameter to language service constructor
internal/fourslash/fourslash.go	Implements user preferences configuration support for testing
internal/fourslash/tests/autoImportCompletion_test.go	Adds test case for user preferences functionality
internal/api/api.go	Updates language service instantiation to include user preferences

[jakebailey]

This handler is set up, but I don't think the PR sets up the watch capability yet.

[jakebailey]

Are you planning to do this now, or in the future?

[iisaduan]

Future

[jakebailey]

Unfortunately there is also javascript and js/ts scopes we might need.

I think we're going to have to make user prefs have both variants and then return one or the other depending on the situation...

[jakebailey]

Not blocking for this PR, but needs to be done eventually.

[andrewbranch]

This should be protected by a mutex (you can reuse s.pendingConfigChangesMu, maybe with a rename and change to a RWMutex)

s.compilerOptionsForInferredProjects would be in the same boat except that it’s literally never read 🤔

[andrewbranch]

I don’t love the mix of terminology. Can we either standardize everything to use LSP terminology (workspace configuration) or say, once the “workspace configuration” has been filtered and parsed into stuff the language service cares about, we refer to that bit consistently as user preferences?

[jakebailey]

I would prefer the latter, as in "try to resolve settings to a clearer set of shared options and use that".

[jakebailey]

This sort of blocks fixing #1914; would be really good to get some form of this in so we can start improving other stuff in the meantime, I think.

[iisaduan]

Im currently fixing merge conflicts with this, and I should be able to address a lot of the formatting issues immediately after this is in.

Before I left I was fixing a server crash that happened with didChangeNotification. I fixed that as well, but I'm not sure it's 100% registered correctly at initialization. We need didChangeNotification (or some other back door) for fourslash, but we didn't support it previously, especially not for userPreferences

[jakebailey]

Is this challenging to fill out? This is where we are wanting it next, I believe.

[iisaduan]

I'm working on it at the moment, I didn't want to bog this PR down farther

[iisaduan]

it's not an insignificant add, I'll need to do pretty much the handling in the same places as i did for userpreferences-- pretty much do another version of everything except the actual server/client request, and I would like to get this PR in to finalize the server/client request and the general userPreferences lifecycle handling in snapshot/session at least. It'll be a lot easier to add on other kinds of settings (like format) if I'm not worried about needing to change those things

[jakebailey]

Tried on my machine, and I see it making the client request and it seems to be okay. Good to get started in any case (but what I'm reading here seems fine)

outdated