Add luau-lsp files to the viewer

[tapple]

• Part of Improve keywords files for SLua and LSL #5299

These are the two files that any installation of the Luau Language Server (luau-lsp) needs to make sense of slua code. Currently, vscode plugin builds these two files based on these two files it fetches from the viewer:

• types_lua_default.xml
• keywords_lsl_default.xml (except it uses the version from the simulator capability)

Instead, I propose the viewer and/or simulator keep these two files on-hand so that the vscode plugin and other editors (including the viewer's builtin editor) can handle slua without complex file transformation.

These two files were generated by the latest unreleased version of the vscode plugin. Further auto-generated updates to these files will be in a seperate PR #5328 (View the diff)

---

Part of a set:

• Generate slua_default.d.luau file lsl-definitions#42
• Add luau-lsp files to the viewer #5327
• Update luau-lsp files #5328

[marchcat]

Thank you, @tapple!

[marchcat]

@Rider-Linden, please take a look.

[Rider-Linden]

The d.luau files are uses only by Lua LSPs that are forked from JohnnyMorganz' luau-lsp plugin. Although one of the most popular there are other plugins and editors that do not use the .d.luau format we would like to support (Neovim, Zed, Helix).

Delivering the JSON and having the plugin generate the appropriate configs file strikes me the correct approach.

I don't object to providing these two files as a reference but it should be made clear that they are not canonical.

[tapple]

These ones I found use JohnnyMorganz luau-lsp:

• neovim: https://github.com/lopi-py/luau-lsp.nvim
• zed: https://zed.dev/docs/languages/luau
• helix: Having trouble configuring lsp for Helix editor JohnnyMorganz/luau-lsp#463

I can't quickly find any editors supporting luau that don't use JohnnyMorganz luau-lsp

[HaroldCindy]

Hmm, realistically, luau-analyze itself isn't sufficient for our purposes, and we need luau-lsp to be able to describe our API extensions correctly. luau-lsp is the choice of LSP for Luau, so I wouldn't feel too badly about depending on it for type checking. It also provides luau-lsp analyze for that purpose.

[HaroldCindy]

Spoke with @Rider-Linden about this. Seems like really what we want is to send down the current contents of the definitions YAML (maybe reserialized as JSON for the JSON-RPC stuff) to external consumers, rather than bundle a generated artifact from that source of truth that the viewer itself will not use. The keywords XML will probably have to remain in-repo because the in-viewer editor's syntax highlighting impl is a bit of a weird case, but otherwise we're looking at providing a way for the JSON-RPC clients to get the full definitions blob the server is currently using. They can generate whatever schema they want (.d.luau, Selene definition, etc) based on that blob.

[tapple]

Oh. Selene uses a third format I was unaware of: https://kampfkarren.github.io/selene/usage/std.html

If that's the official consensus though, I guess I'll work on generating types_lua.xml and updating the vscode plugin to work with the changes I made to its schema