Skip to content

require failures in bsconfig should produce a diagnostic and not crash the LSP process #1690

@TwitchBronBron

Description

@TwitchBronBron

Currently, when a require entry in bsconfig.json fails (e.g. missing module, syntax error in plugin), it throws an unhandled exception that takes down the entire LSP process. This is too destructive — a broken plugin in one project should not kill language intelligence for all open projects.

Proposed changes

  • Wrap each require call in a try/catch
  • Track the exact line/column position of the failing require entry in bsconfig.json so we can emit a proper diagnostic pointing to it
  • Emit a logger.error(...) entry when a require fails
  • Instead of crashing, signal to the LSP that this specific project failed to load (without bringing down the whole server)
  • On initial startup: collect all project activation errors and send a single consolidated error message to the LSP client (rather than one popup per project — that's too noisy)
  • On subsequent per-project reloads (e.g. bsconfig change): send an individual error for that project only

Why

One bad plugin or misconfigured require path should not break the LSP for all other projects in the workspace. Diagnostics should surface the problem precisely in bsconfig.json at the offending line.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions