sourcery icon indicating copy to clipboard operation
sourcery copied to clipboard

VSCode is scanning excluded files in `node_modules/`

Open tylerlaprade opened this issue 1 year ago • 5 comments

Checklist

Description

image

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

tylerlaprade avatar Jul 19 '24 13:07 tylerlaprade

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?

Hellebore avatar Jul 19 '24 14:07 Hellebore

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.

tylerlaprade avatar Jul 19 '24 15:07 tylerlaprade

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:

ruancomelli avatar Jul 24 '24 18:07 ruancomelli

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/.

image

tylerlaprade avatar Jul 24 '24 21:07 tylerlaprade

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, then uv sync in this folder
  • Create a file in the workspace at example.py with a from datetime import datetime import
  • Ctrl+Click on the datetime symbol 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.py as 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.

blakeNaccarato avatar May 07 '25 18:05 blakeNaccarato