Current state
Config resolution capability is asymmetric between the two entry points:
- CLI: supports
--config <path> to explicitly specify a config file;
- LSP: no equivalent. Config is discovered entirely server-side by scanning from cwd for fixed file names (
rslint.config.{js,mjs,ts,mts} / rslint.json(c)).
Scope note: the LSP server currently reads no client input at all — runLSP (cmd/rslint/lsp.go) does not parse its argv, and nothing in internal/lsp reads initializationOptions; the server's only workspace anchor is its cwd at spawn. So this proposal is about adding a new input channel, not plumbing the existing CLI flag through.
Precedent: the programmatic --api surface already accepts client-supplied config (LintOptions.config / configDiscovery.overrideConfig, decoded Go-side in cmd/rslint/api.go), so client-designated config is an established concept in the codebase — this extends it to the LSP surface.
Motivation
- General need: users whose config lives at a non-conventional location / file name currently have no way to use it in editors (LSP). Peer tools already provide this: Biome
biome.configurationPath, Oxc oxc.configPath.
- Concrete scenario: the unified rstack editor extension. rstack-cli users may have only
rstack.config.ts (define.lint()) and no rslint.config.* at all; rs lint works on the CLI side by injecting --config <rstack>/dist/rslintConfig.js (a shim). The editor needs a long-lived LSP, and the same bridging requires the LSP to accept an explicit config path.
Layering note: rslint does not need to know anything about rstack — what it receives is just an absolute path to an ordinary JS config file, no different from a hand-written rslint.config.js. All bridging logic lives in the editor extension.
Proposal
Add the ability for the LSP client to explicitly specify a config path, with semantics aligned to the CLI's --config (resolution roots stay anchored at the server cwd, not the config file's directory).
Suggested channel: initializationOptions — the client passes a mapping like { "<folderOrDir>": "<absoluteConfigPath>" } at initialize. Static per spawn is sufficient: when the designation changes (e.g. the user adds a native rslint.config.ts and the client switches back to default discovery), the client restarts the server — the client manages the server lifecycle anyway. A dynamic mechanism (e.g. a field on rslint/configRefresh) would work too; the final shape is up to the maintainers. When nothing is specified, behavior is unchanged.
If the direction sounds good, we're happy to submit a PR.
Current state
Config resolution capability is asymmetric between the two entry points:
--config <path>to explicitly specify a config file;rslint.config.{js,mjs,ts,mts}/rslint.json(c)).Scope note: the LSP server currently reads no client input at all —
runLSP(cmd/rslint/lsp.go) does not parse its argv, and nothing ininternal/lspreadsinitializationOptions; the server's only workspace anchor is its cwd at spawn. So this proposal is about adding a new input channel, not plumbing the existing CLI flag through.Precedent: the programmatic
--apisurface already accepts client-supplied config (LintOptions.config/configDiscovery.overrideConfig, decoded Go-side incmd/rslint/api.go), so client-designated config is an established concept in the codebase — this extends it to the LSP surface.Motivation
biome.configurationPath, Oxcoxc.configPath.rstack.config.ts(define.lint()) and norslint.config.*at all;rs lintworks on the CLI side by injecting--config <rstack>/dist/rslintConfig.js(a shim). The editor needs a long-lived LSP, and the same bridging requires the LSP to accept an explicit config path.Layering note: rslint does not need to know anything about rstack — what it receives is just an absolute path to an ordinary JS config file, no different from a hand-written
rslint.config.js. All bridging logic lives in the editor extension.Proposal
Add the ability for the LSP client to explicitly specify a config path, with semantics aligned to the CLI's
--config(resolution roots stay anchored at the server cwd, not the config file's directory).Suggested channel:
initializationOptions— the client passes a mapping like{ "<folderOrDir>": "<absoluteConfigPath>" }atinitialize. Static per spawn is sufficient: when the designation changes (e.g. the user adds a nativerslint.config.tsand the client switches back to default discovery), the client restarts the server — the client manages the server lifecycle anyway. A dynamic mechanism (e.g. a field onrslint/configRefresh) would work too; the final shape is up to the maintainers. When nothing is specified, behavior is unchanged.If the direction sounds good, we're happy to submit a PR.