Disable built-in stubs

[TrevinAvery]

I want to disable all built-in stubs.

Use Case

In my pipelines I want to run Pyright via CLI on new PRs to ensure that all typing errors have been addressed. To prevent unexpected errors in the pipelines, I need the output of VS Code's Pylance and the Pyright CLI to be identical. Using a pyrightconfig.json file will ensure that the settings are the same, however, it does not ensure that the same stubs are installed.

In my case, I am using Django. When running the Pyright CLI, since I don't have django-stubs installed, I get more errors in the CLI than I do in VS Code. This means when making a PR from VS Code, it may look like everything is just fine, but the pipeline check will fail.

I realize the solution here is to install django-stubs, which I will need to do with or without this feature. But what I want to avoid is silent failures. I want to know that the pipeline will fail before I submit the PR. By disabling the built-in stubs, I will be alerted that they are missing from my dependencies and I can actively install them. Additionally, if Pylance updates to add or remove any stubs, my workflow will be unaffected. And if I need a different version of stubs than what Pylance has installed, I can know that it is using my locally installed version.

Design Requirement Suggestions

1. The minimum solution here would be to simply disable all built-in stubs via a single setting in VS Code. This way I know VS Code will always show the same errors that the Pyright CLI will show, and to fix some of them I will need to add the stubs to my environment dependencies.
2. A slight improvement would be to enable and/or disable specific stubs in the settings.
3. And the true ideal would also add a note to the error output stating that the built-in stub is disabled and they can either enable it or install it in the local environment.

[github-actions[bot]]

Hi @TrevinAvery, I'm an AI Support assistant here to help with your issue. While the team reviews your request, I wanted to provide some possible tips and documentation that might help you in the meantime.

---

Potentially Related Issues:

• Provide an option to disable specific stubs in settings – discussion about ignoring bundled stubs per package. #2663
• How can I disable the bundled SQLAlchemy stubs? – workaround and discussion for SQLAlchemy stubs. #3005
• Project typings directory overriding bundled stubs – technique to let local stubs take precedence. #945
• Disable navigation into stubs – request to prevent “Go To Definition” from opening stub files. #65

---

The team will respond to your issue shortly. Please note this is a trial feature and may not be fully accurate. I hope these suggestions are helpful in the meantime. If this comment helped you, please give it a 👍. If the suggestion was not helpful or was incorrect, please give it a 👎. Your feedback helps us improve!

[bschnurr]

In the past I believe some users have added stubs to their pyright cli by downloading them from here: https://github.com/microsoft/python-type-stubs#installing-our-stubs

[TrevinAvery]

The could be helpful, but I don't think it is sufficient. What if I want to use a different version of a stub? Is pylance going to respect the version I have installed in my project? Or will it conflict? Even if it happens to resolve correctly, I fear there will always be a bit of user confusion or uncertainty. The easiest way to ensure any user can configure this to their needs is to allow fully disabling the built-in stubs.