Follow-up from "Support minimum language server client restriction"
The following discussions from !193642 (merged) should be addressed:
-
@jessieay started a discussion: (+1 comment) Question: what happens if the minimum client version is set but not enforced? Why have 2 separate settings rather than just having the minimum version and, if set, enforcing that version?
-
@jessieay started a discussion: (+1 comment) Nit:
language_server_restrictions_enabledwould be a better name, in my opinion, because it puts the unique piece of the name (noun) before the verb. But not a blocker😄 -
@jessieay started a discussion: (+1 comment) Nit (non-blocking): should we be clearer that this is due to the client being too old and suggestion an update so this error is more actionable?
-
@jessieay started a discussion: (+1 comment) Question (non-blocking): should we indicate what the setting is set to for the gitlab.com instance?
-
@jessieay started a discussion: (+1 comment) Question (non-blocking): should we set a default value here? Since it is disabled by default, having a default is a helpful no-op in case they do enable. Downside is we'd want to regularly update the default
🤔 -
@jessieay started a discussion: (+1 comment) Suggestion (non-blocking): add a test case where
enable_language_server_restrictionsisfalseandclient_versionis less thanminimum_language_server_version(set on L726). This should be allowed -
@jessieay started a discussion: (+1 comment) Hi @erran - I have non-blocking feedback for you. Want to handle these in a follow up? The only one that would potentially be more annoying to do later than now is the json schema rename...and possibly removing
enable_language_server_restrictionsaltogether, if we want to assume that any timeminimum_language_server_versionis set, it is enforced.let me know how you want to proceed!