facebook / facebook/pyrefly

Feature Request: External Config Provider for LSP

Open
#3,512 10 comments 0 reactions 1 assignee Claimed by @kinto0 View on GitHub
configuration language-server stale
Dominant language
Rust
Stars
7k
Forks
519
PR merge metrics
No merged PRs in 30d

Description

We are working on enabling type checking in our large monorepo at Arista Networks. We use a custom built build system (has similar Bazel-style workflows) which we rely on as the source of truth for which files are typechecked with which configs. The current options with the LSP do not scale well with our workflows to improve the developer QoL:
- Maintaining up to multiple `pyrefly.toml` in every package creates a maintenance burden to keep it synced with the build system's config.
- Using `[[sub-config]]` in a centralized config with hundreds of sub-config entries is also a massive maintenance burden.

The current options also do not offer a clean solution in repositories where type checking is incrementally added. I.e., some files have stricter settings compared to others. It also looks like the existing `[build-system]` integration with Buck2 or for custom invocations solves import resolution/dependency mapping, but does not provide any type checking config.

### Proposal
To add an external config provider. This is a user specified command that the Pyrefly LSP can call to resolve the configuration for a given source. This can be configured as an option to the `pyrefly lsp` command.

The protocol would involve two subcommands:
1. ` resolve`: Get the config file for a given Python file. Pyrefly loads it into `ConfigFile` and caches it
2. ` invalidate`: Check for stale configs, and return a list of files/globs to evict from the cache. This could be configured to be polled intermittently

To maintain compatibility, this would be an opt-in feature. If selected, it would take precedence over filesystem config discovery. Pyrefly would also fall back to the default behavior in case of any issue in the user's provider.

With this feature, teams like ours can use a lightweight script to query the build system's metadata and return the correct config file. This avoids the alternative: maintaining thousands of toml files scattered throughout the repo to get the LSP working correctly.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.