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:
<config-provider> resolve: Get the config file for a given Python file. Pyrefly loads it into ConfigFile and caches it<config-provider> 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.
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:
pyrefly.tomlin every package creates a maintenance burden to keep it synced with the build system's config.[[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 lspcommand.The protocol would involve two subcommands:
<config-provider> resolve: Get the config file for a given Python file. Pyrefly loads it intoConfigFileand caches it<config-provider> invalidate: Check for stale configs, and return a list of files/globs to evict from the cache. This could be configured to be polled intermittentlyTo 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.