Feature Request: External Type Checking Configuration Provider

[saimster-arista]

Our Problem

Pylance currently resolves type checking configuration from a single pyrightconfig.json at the workspace root. This model works well for standalone projects but struggles short in large monorepos with custom build systems (similar to Bazel-style workflows) where:

1. Different files require different type checking configurations: Our monorepo contains ~3800 packages, each with its own strictness level and custom typechecking overrides. A single workspace-root config struggles to represent this.

2. Workspace roots are fluid: We frequently switch between packages and open multiple packages in multi-root workspaces. This makes maintaining a pyrightconfig.json in every package directory a burden. We've considered generating them on the fly, but this isn't practical.

3. The build system provides the source of truth: Our build system knows which pyright config applies to each file. Each package declares its own type checking strictness level, and the build system already runs pyright with the correct config per file during CI. Unfortunately, there is no way to communicate this information to Pylance.

Existing features considered

We've looked into similar feature requests and stumbled upon a few. We considered the following features, but they don't work well for our uses: executionEnvironments from #4059

• This was added to support per-directory config overrides within a single pyrightconfig.json. This works well for projects with a handful of distinct environments, it doesn't scale to our use case. We cannot maintain 3800 entries and sync the config with the build system's per-package settings.

Our Proposal

Add support for a configuration provider. We believe implementing a local daemon/service that Pylance can query to resolve type checking settings on a per-file basis would be very practical. Users implement and run the daemon themselves with Pylance defining the interface and providing a consumer. This would provide an opt-in approach that is configurable by the users, and should require minimal maintenance by the Pylance team.

How it would work

Below is rough idea of how this would be used and configured.

1. New Pylance settings:

   • python.analysis.configProvider.enabled: enable the external config provider
   • python.analysis.configProvider.endpoint: address of the local daemon (e.g., a Unix socket path)

2. Interface contract with the config provider: Pylance sends a request with a file path and receives a response containing the pyright configuration to apply for that file:

   Request:

   {
     "filePath": "/src/MyPackage/mymodule.py"
   }

   Response:

   {
     "typeCheckingMode": "strict",
     "reportMissingTypeStubs": "none",
     "reportUnknownVariableType": "none",
     "reportUnnecessaryTypeIgnoreComment": "error"
   }

   The response schema would match the existing pyright configuration keys.

3. Fallback behavior: If the daemon is unreachable or returns an error for a given file, Pylance should fall back to the standard resolution for typechecking configs.

4. Caching: Pylance could cache responses per file path to avoid repeated requests, and the daemon can optionally include a TTL per-file.

Our use case

With an external config provider, we would run a lightweight daemon that reads our build system's metadata and responds with the correct pyright config for any given file. This would provide developers with accurate, per-file diagnostics in Pylance with zero manual configuration. This would alleviate the need to generate thousands of individual pyrightconfig.json files or maintain a massive pyrightconfig.json with executionEnvironments configured.

We believe this will help decouple Pylance from implementing niche user requests. Anyone can implement their own config provider with arbitrary complexity.

[rchiodo]

Thanks for the suggestion. Moving to discussion item for up votes.