Unify tsdk between built-in and native preview extensions

[DanielRosenwasser]

The native preview extension should be able to leverage the same tsdk setting as the built-in VS Code extension.

That may not mean that the native preview's tsdk setting needs to be ignored/deprecated - users might want to specify a given tsdk for Strada and Corsa side-by-side.

When useTsGo is true or undefined, we should try to use the directory.

• If it points to a TS7 directory, then we should use the server there.
• Otherwise, if useTsGo is true, we should use the built-in server.
• Otherwise, we should not start the TS7 server at all.

[DanielRosenwasser]

We may need some sort of marker file to tell us "this is a TS7 directory".

[DanielRosenwasser]

So what we've figured is that both the Strada & Corsa extensions need to sync up on some behavior here before deciding to activate their respective servers. I don't exactly know how this works for a workspace-less folder, but I think it would only differ based on the context-based user preference.

Here's how I think we should do it.

1. Retrieve the values of the tsdk setting and the useTsgo setting.

2. If tsdk is empty, defer to using the built-in language service, and base this on the retrieved value for useTsgo. Done

3. Otherwise, retrieve workspace storage (i.e. get the memento's value) for whether the user wants to actually use the tsdk. If not, defer to using the built-in language service based on the useTsgo setting. Done.

4. Resolve whether tsdk points towards a Strada, Corsa, or Invalid folder. This is determined via the presence of tsserver.js or lib/tsserver.js

5. If the tsdk points to an Invalid SDK folder, defer to using the built-in language serviceand base this on the retrieved value for useTsgo. Done

6. If the tsdk points to a Strada SDK and useTsgo is false, use Strada. Done.

   Note: This is true even if useTsgo and tsdk are set in differing scopes.

7. If the tsdk points to a Corsa SDK and useTsgo is true, use Corsa. Done.

   Note: This is true even if useTsgo and tsdk are set in differing scopes.

8. Retrieve the scopes (e.g. workspace, global, default) for the tsdk and useTsgo settings.

   Note: At this point, the two diverge.
   We will leverage the setting that has the highest precedence.

9. If tsdk has higher precedence, use its SDK. Done

10. Otherwise, defer to using the built-in language service, and base this on the retrieved value for useTsgo. Done

[andrewbranch]

Here's what I'm thinking.

The process for deciding which extension to use and what tsdk to use:

flowchart TD
    A{"memento:<br>useWorkspaceTsdk"} -->|true| B{"workspace setting:<br>js/ts.tsdk.path"}
    A -->|"false / unspecified"| C{"user setting:<br>js/ts.tsdk.path"}

    B -->|Corsa| WC["Corsa + workspace tsdk"]
    B -->|Strada| WS["Strada + workspace tsdk"]
    B -->|unspecified| C

    C -->|Corsa| GC["Corsa + user tsdk"]
    C -->|Strada| GS["Strada + user tsdk"]
    C -->|unspecified| H{"resolved setting:<br>js/ts.lspEnabled?"}

    H -->|true| DC["Corsa + its built-in tsdk"]
    H -->|false| DS["Strada + its built-in tsdk"]
    H -->|unspecified| K{"Experiment rollout:<br>use Corsa?"}

    K -->|yes| DC
    K -->|no| DS

    style WC stroke:#28a745,stroke-width:3px
    style GC stroke:#28a745,stroke-width:3px
    style DC stroke:#28a745,stroke-width:3px
    style WS stroke:#0366d6,stroke-width:3px
    style GS stroke:#0366d6,stroke-width:3px
    style DS stroke:#0366d6,stroke-width:3px

Loading

So there are only four variables that control what to use, in decreasing priority order:

1. useWorkspaceTsdk memento—this is not a JSON setting; this is the local workspace state that gets set by a UI prompt. This is what makes it possible for a user to have a workspace-defined tsdk but opt to use VS Code's builtin version instead.
2. The tsdk JSON setting—resolving it is more complicated than normal settings resolution because (1) makes it possible to ignore a workspace setting, which usually has higher precedence than a user setting.
3. The newly proposed lspEnabled (naming bikesheddable) JSON setting that indicates whether to consider Corsa VS Code's built-in version.
4. Whether the machine is opted into staged/experimental rollout of enabling Corsa by default. If we chose not to do a gradual rollout, we would instead just pick Corsa or Strada as the ultimate default when no other settings are specified.

Implementation notes:

• Presumably, this selection algorithm would be implemented by both extensions simultaneously and cause each of them to decide whether to soft-deactivate, like useTsgo does today. However, when the useWorkspaceTsdk memento is false or undefined but a workspace TS installation is detected in node_modules, a UI prompt is fired. Both extensions implement this currently (gated by useTsgo so only one happens at a time). I think it might be easiest to make one extension (call it "primary") in charge of managing the prompt and storing the memento, and the secondary extension can ask the primary for the value of useWorkspaceTsdk. There are other ways of doing this, but it will have to be handled somehow so that both extensions can run the selection algorithm, get the same result, and only prompt once.

• We decided that the presence of tsserver.js in a tsdk directory is enough to determine whether a directory is Corsa or Strada.

• Another piece of UI that would be good to unify is the version selector. Currently, the command palette menu is contributed by both extensions, and the built-in one is visible (but immediately shows an error) when using Corsa. We could probably fix it showing up when it shouldn't, or again delegate the responsibility to one extension or the other, and have them communicate.

  As for what versions to show in the picker, the easiest thing would be to show the workspace version and the "built-in version," where "the built-in version" is chosen by the resolution of the js/ts.lspEnabled setting, falling back to the experimental rollout status—i.e., the branch of the flowchart beginning at “resolved setting: js/ts.lspEnabled.” We could show both the built-in Strada version and the built-in Corsa version, but this would necessitate potentially writing/changing js/ts.lspEnabled in workspace settings to make the flowchart algorithm result in the UI-selected version.

• The ability of extensions' activate() function to return a callable API will be useful in all this communication.