sourcery
sourcery copied to clipboard
VSCode is scanning excluded files in `node_modules/`
Checklist
- [x] I have searched the Sourcery documentation for the issue, and found nothing
- [x] I have read the common issues and fixes listed in the Sourcery troubleshooting page, and found nothing
- [x] I have checked there are no open bugs referencing the same bug or problem
Description
Code snippet that reproduces issue
ignore: # A list of paths or files which Sourcery will ignore.
- .git
- venv
- .venv
- env
- .env
- .tox
- node_modules
- .dev-run
- build
Debug Information
IDE Version: VSCode 1.91.1
Sourcery Version: Sourcery v1.21.0
Operating system and Version: macOS Sonoma 14.5
Hi @tylerlaprade - thanks for raising this.
I can't reproduce this at first attempt - could you let me know the structure of your workspace, i.e. which folder do you have open in vscode, are there multiple ones?
I have one big monorepo with both my front-end and back-end code nested in directories. Just one folder. This "scanning" message remained for many minutes, so eventually I did Developer: Reload Window to get rid of it.
Hey, @tylerlaprade!
Currently, Sourcery interprets the paths listed in the ignore field relative to the project root path. Therefore,
ignore:
- node_modules
will instruct Sourcery to ignore ./node_modules, but not e.g. ./frontend/node_modules (supposing here that frontend/ is the name of the directory where your front-end code is stored).
To fix this, you need to provide the path to the node-modules directory in your project including intermediate directory names:
ignore:
- frontend/node_modules
Could you please try this solution and let me know if it works for you? :slightly_smiling_face:
Thanks! I'm not sure how to trigger that "scanning" thing since it just showed up in my status bar one day, but I still see squiggles from Sourcery if I open up a file from paqarina/node_modules/.
This also happens e.g. with VSCode's Sourcery extension scanning and providing problems output for paths in uv's provided Pythons. For instance:
- Open a new folder in VSCode, e.g.
example - Run
uv init --bare, thenuv syncin this folder - Create a file in the workspace at
example.pywith afrom datetime import datetimeimport Ctrl+Clickon thedatetimesymbol to navigate to the standard library implementation. In my case, you arrive at%APPDATA%/uv/data/python/cpython-3.11.10-windows-x86_64-none/Lib/datetime.py.- Now, close this tab pointing to a standard library implementation.
- Upon returning to
example.pyas your active tab, Sourcery lights up the problems pane with tons of problems, having scanned the following files (sometimes others...) and reporting problems in them:%APPDATA%/uv/data/python/cpython-3.11.10-windows-x86_64-none/Lib/datetime.py%APPDATA%/uv/data/python/cpython-3.11.10-windows-x86_64-none/Lib/typing.py%APPDATA%/uv/data/python/cpython-3.11.10-windows-x86_64-none/Lib/operator.py
- These problems stick around for quite awhile, cluttering the problems pane. They can be cleared reliably by closing out VSCode entirely and reopening the workspace, and these superfluous problems also "fall off" or disappear after about ~5 minutes or after some unknown course of action is taken
Since some things like typing.py stdlib get pulled in in addition to datetime.py, I wonder if this is a weird Pylance/Sourcery interaction. Anyways, you can't resolve it in .sourcery.yaml with any kind of ignore configuration, because ignores don't support recursive globs like ** nor do they permit "ignoring" anything outside of the current working directory, even if absolute paths are hard-coded there.
Workaround
Add !**/AppData to your Problems pane "Filter" list, or e.g. !**/wherever-sourcery-is-walking-that-i-don't-care-about. This doesn't stop Sourcery from traversing those files (which can be a performance issue which is what I comment on in https://github.com/sourcery-ai/sourcery/issues/405#issuecomment-1875886331), but at least it stops cluttering the pane.
But since https://github.com/microsoft/vscode/issues/195586 staled out, the Problems pane badge count will give you the count of all issues including those red herrings in e.g. %APPDATA%, so you'll be bothered by an inflated problems badge count for ~10 minutes every time you traverse definitions into third-party or stdlib code.