镜像站点 · 本页由第三方 GitHub 只读镜像提供,非 GitHub 官方站点,不接受任何登录或凭据输入。前往 github.com
Skip to content

Refactor wish list #1094

Open
Open

Description

@nojaf

As mentioned here, it would be great to refactor the extension and LSP server. Here are some ideas to consider; please feel free to raise other points or challenge any listed:

  • Use promises in the LSP server, as many endpoints spin a binary or read files.
  • Refactor incrementalCompilation.ts and implement an interface to handle the differences between bsb and rewatch, as those checks are scattered throughout the code.
  • Utilise semver for more version checks.
  • Enable more logging in the output window; see Initial SendLogNotification #1066. Wink @zth.
  • Employ a formatter (e.g., prettier/biome), as our lack of it is quite annoying.
  • Remove chokidar from the LSP server and use the [DidChangeWatchedFiles Notification] instead.
  • Bump the TypeScript version, as we likely have an outdated one.
  • Consider removing ESBuild; do we still need to bundle?
  • Should we implement the mono-repo structure properly? Currently, we have three package.json files, and the top one lacks a workspaces entry.
  • Use yarn as we do in rescript compiler?
  • Update CONTRIBUTING.md, as it may no longer be accurate.
  • switch from TextDocumentSyncKind.Full to TextDocumentSyncKind.Incremental

Let me know your thoughts, @zth, @cometkim, @mediremi!

Activity

  1. fhammerschmidt commented on May 16, 2025

    @fhammerschmidt
    Member

    At some point the server part should be in OCaml (#269).
    Then we only have a small client left where we could get rid of the typescript dependency entirely. The client might not be too much work to rewrite in ReScript instead?

  2. nojaf commented on May 16, 2025

    @nojaf
    ContributorAuthor

    At some point the server part should be in OCaml (#269).

    True, but all the above are feasible. I started working on an OCaml LSP some time ago: https://github.com/nojaf/rescript/tree/lsp. It is a lot of work, and I became a bit demotivated upon learning that the analysis-tool currently relies on being run as a single execution. During the retreat, there was also mention of possibly doing this in Rust. I'm not sure which option is the lesser evil, though.

  3. nojaf commented on May 16, 2025

    @nojaf
    ContributorAuthor

    The client might not be too much work to rewrite in ReScript instead?

    Yeah, that could be fun to have in the end.

  4. mediremi commented on May 16, 2025

    @mediremi
    Member

    We probably want to switch from TextDocumentSyncKind.Full to TextDocumentSyncKind.Incremental (see "Incremental Text Document Synchronization" from the language server extension guide) and use VS Code's TextDocuments documents manager instead of rolling our own file content cache as we currently do.

    import {
      createConnection,
      TextDocumentSyncKind
    } from 'vscode-languageserver/node';
    import {
      TextDocuments
    } from 'vscode-languageserver';
    import { TextDocument } from 'vscode-languageserver-textdocument';
    
    const connection = createConnection();
    const documents = new TextDocuments(TextDocument);
    documents.listen(connection);
    
    connection.onInitialize(() => ({
      capabilities: {
        textDocumentSync: TextDocumentSyncKind.Incremental
      }
    }));
    
    connection.listen();
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions