`is_vscode_project` should probably look for `.vscode/settings.json`

[jennybc]

I have some regret about the current definition of is_vscode_project (which is my fault):

rprojroot/R/root.R

Line 316 in 97b875b

is_vscode_project <- has_dir(".vscode")

Why? Because a VS Code user will probably have a .vscode/ folder in their home directory. So this has the potential to make (basically all 😬) other directories appear to be nested inside an existing project, which is something usethis aggressively checks for and discourages.

> create_project("~/tmp/blah")
! New project "blah" is nested inside an existing project /Users/jenny/tmp/, which is rarely a good idea.
ℹ If this is unexpected, the here package has a function, `here::dr_here()` that reveals why /Users/jenny/tmp/
  is regarded as a project.
Do you want to create anyway?

1: Absolutely not
2: No way
3: Yes

Selection: 
2
Run `rlang::last_trace()` to see where the error occurred.
Error in `challenge_nested_project()`:
✖ Cancelling project creation.
Show Traceback

> withr::with_dir(new = "~/tmp", here::dr_here())
here() starts at /Users/jenny.
- This directory contains a directory '.vscode'
- Initial working directory: /Users/jenny/tmp
- Current working directory: /Users/jenny/tmp

I now think this criterion should be more specific and look for .vscode/settings.json, which is characteristic of a project directory.

User-level settings are generally stored elsewhere, i.e. I don't expect to see ~/.vscode/settings.json. By platform, here are the typical places for user-level settings:

• macOS: ~/Library/Application Support/Code/User/settings.json
• Windows: %APPDATA%\Code\User\settings.json (typically C:\Users\{username}\AppData\Roaming\Code\User\settings.json)
• Linux: ~/.config/Code/User/settings.json

Here's what I have in ~/.vscode/, which I think is fairly typical and notably does not include settings.json:

~ % ls -al ~/.vscode
total 24
drwxr-xr-x@  6 jenny  staff   192 Jan 14  2025 .
drwxr-x---+ 74 jenny  staff  2368 Jul 22 18:37 ..
-rw-r--r--@  1 jenny  staff  6148 Jul 21 09:38 .DS_Store
-rw-r--r--@  1 jenny  staff   798 Jan 13  2025 argv.json
drwxr-xr-x@  2 jenny  staff    64 Jan 13  2025 cli
drwxr-xr-x@ 32 jenny  staff  1024 Jul 22 11:18 extensions

PR incoming!

[krlmlr]

Thanks. Let's discuss:

• how a settings.json is typical of a "proper" project
  • I looked at my .vscode projects, quite a few didn't have this file
• how is this difficult from any other "project" that is accidentally created in the user's home
  • just saw it -- argv.json and other directories
• if we could instead check for non-presence of an argv.json or the other directories
  • Chat hallucinates about that file's location, I couldn't find authoritative documentation with a quick search
  • is it honored when in a project-local .vscode ?
• if there's an alternative approach that works for all project kinds: stop when the user's home is reached
  • breaking change: projects in the user's home are never recognized
  • does this solve the issue at hand?

What do you think?

[jennybc]

how a settings.json is typical of a "proper" project
I looked at my .vscode projects, quite a few didn't have this file

You can't count on the presence of .vscode/settings.json in a folder you have opened in VS Code or Positron. However, if it's there, it means the user has opened this folder in VS Code or Positron and has bothered to save some workspace-specific settings.

Side observation: any folder that is setup for Air, using the recommended setup, will have .vscode/settings.json.

if we could instead check for non-presence of an argv.json or the other directories

I did do some research as I developed this issue and PR and I am pretty convinced that presence of settings.json is a good way to distinguish the VS Code/Positron stuff at user-level vs. at workspace-level. I didn't do specific research about argv.json, but my hunch is that that could be used at either level. According to copilot, at least, it is only relevant at the user level.

stop when the user's home is reached

Yeah I thought about that. So it's not out of the question. But I feel like that has (at least) two downsides:

• Introduces a composite criterion. So is_vscode_project becomes less parallel to the other criteria, in that it does what it days on the tin (does this look like a vscode project?) AND also does something else (does this NOT look like user's home directory?)
• Drags rprojroot into the whole matter of what is the user's home directory, which is especially fraught on Windows.

[krlmlr]

Thanks. Thinking about it, I agree it's a good compromise. I'll push an update to CRAN soon.

How do you feel about another criterion that looks for a *.code-workspace file?

[jennybc]

How do you feel about another criterion that looks for a *.code-workspace file?

I have neutral-to-mildly-negative feelings. Mostly neutral. The reason I'm mildly negative is that I really don't think many people need explicit workspaces and I really don't want folks using them unless truly necessary. I would sit tight with this new detection of .vscode/settings.json and see if users come out of the woodwork truly needing more.