wasp/waspc/waspls
Craig McIlwrath 0f9726b7a1
[waspls] use the wasp project root instead of the workspace root (#1393)
* calculate project root via location of .wasp file

previously, waspls used workspace root, which was incorrect if you opened a
workspace larger than the wasp project.

this does not add support for multi-project workspaces.

* update changelog with waspls scaffolding info
2023-08-11 08:18:37 -04:00
..
src [waspls] use the wasp project root instead of the workspace root (#1393) 2023-08-11 08:18:37 -04:00
test [waspls] Add code actions for scaffolding external code (#1316) 2023-07-26 08:00:16 -04:00
README.md [waspls] diagnostics for external imports and goto definition (#1268) 2023-06-22 15:37:07 -04:00

waspls Architecture

waspls uses the lsp library for interacting with the Language Server Protocol.

The main entry point is serve in Wasp/LSP/Server.hs. This function sets up the LSP server, the reactor thread, and starts everything.

The handlers to LSP notifications and requests are defined in Wasp/LSP/Handlers.hs and imported by Wasp/LSP/Server.hs so that the lsp package can be told about them. Mostly, these handlers are small functions to call out to the actual implementation in another source file.

There are two types of handlers in waspls:

  1. "Analysis handlers" that extract some syntactic or semantic information from source code and store it in the server state.
  2. "Request handlers" that use the information stored in the server state to provide LSP features, such as autocompletion and goto definition.

Request handlers have read-only access to the server state, while analysis handlers can write to the state.

Multithreading

By default, the lsp package is single-threaded. Because waspls sometimes needs to do time-intensive work, such as getting the list of exported symbols from TypeScript files, there is a mechanism for running code on a separate thread. The purpose of this is to avoid blocking the main thread for long periods of time, which would make the language server feel unresponsive in the editor.

This mechanism is the "reactor thread," which continuously looks for new actions to run on a separate thread. For details, see the documentation in Wasp/LSP/Reactor.hs.

Testing Development Versions of waspls

Set the wasp executable path in the Wasp VSCode extension to wasp-cli. To build the LSP, run cabal install. Then, restart the language server in VSCode by running the Wasp: Restart Wasp LSP Server command. By default, you can press Ctrl+Shift+P to open the command palette to search for the command.

Note that, after changing the executable path in the extension settings, you have to reload the VSCode window. You can do this either by closing and reopening the window or by running the command Developer: Reload Window.