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.
Currently, when a
requireentry inbsconfig.jsonfails (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
requirecall in atry/catchrequireentry inbsconfig.jsonso we can emit a proper diagnostic pointing to itlogger.error(...)entry when a require failsWhy
One bad plugin or misconfigured
requirepath should not break the LSP for all other projects in the workspace. Diagnostics should surface the problem precisely inbsconfig.jsonat the offending line.