fix(auth): create settings dir before watching it

[John-David Dalton (jdalton)]

Closes SURF-111 ("VSCode is searching for non-existent folder").

On a fresh install of the Socket extension, VSCode logs errors saying it is watching a folder that does not exist. The folder is where the extension saves your API token, and it is only created the first time you log in — but the extension starts watching it the moment it activates, before that folder has ever been created. So every new user gets watcher errors in their log until they log in.

The fix is one line of intent: create the directory (recursively, ignoring any error) right before creating the watcher, so the watcher always points at something real.

Why it happened — the watcher is set up at activation, the folder is created at first login

During activation the extension sets up a file watcher so it can react when the user's saved API token changes on disk. The token is stored at <dataHome>/socket/settings, and the watcher is pointed at the folder that contains it, <dataHome>/socket.

That folder is only created the first time the user logs in and a token is written. Before that first login the folder does not exist, so VSCode's watcher keeps reporting that it is watching a missing directory.

Why creating it early is safe — idempotent, never throws, and the same location the extension already writes to

The extension already writes the token to this exact location on login — this only makes the folder a moment earlier. mkdirSync with recursive: true is a no-op when the folder is already there, and any error is swallowed, so this cannot break activation on a read-only or unusual filesystem.

It uses node:fs (like the scores manager already does for its cache directory) so the behavior is testable with real files; for the local data-home path this is equivalent to the previous vscode.workspace.fs.createDirectory call.

What is covered by tests — both pieces extracted into a pure module, 9 cases

Ran: tsc --noEmit, oxlint, oxfmt --check, and the test suite — all pass locally.

The fix's two pieces are both extracted into src/auth-paths.ts and unit-tested in test/auth-paths.test.mts (9 cases):

• ensureDirectoryExists — the create-before-watch behavior itself, tested against a real temporary directory:
  • creates the directory and any missing parents when absent (the real <dataHome>/socket shape);
  • is a no-op that preserves existing contents when the directory already exists;
  • swallows a failure (a path underneath a regular file) without throwing.
• resolveDataHome — the cross-platform derivation of which directory that is: Windows %LOCALAPPDATA%, Windows throwing when it is missing, $XDG_DATA_HOME, and the macOS and Linux fallbacks.

The ticket text had drifted — this fixes the defect in the title, not the stale scope discussion

The ticket's written description had drifted into questions about API-token scopes and the endpoints npm/score and npm/pkg/ver/issues. Those endpoints belong to the old (pre-rewrite) extension; the current extension calls /v0/purl instead. This PR fixes the reproducible defect named in the ticket title (the missing folder), not the stale scope discussion.

CI is red for an unrelated reason — a fleet-infrastructure failure that affects every PR in this repo

The red Check / Test jobs are a fleet-infrastructure failure in the shared bootstrap step (setup-and-install), which runs before any of this code. The same base tree is green on the main push run but red on pull_request runs; it affects every PR in the repo, not this change. Flagged to the team separately.

[John-David Dalton (jdalton)]

Closing this as obsolete rather than merging it — main has since solved the same problem a different way, and there is nothing left here to land.

This PR fixed a VSCode warning about watching a folder that does not exist yet, by creating the settings directory before pointing a file-system watcher at it. Since then, main moved token storage to vscode.SecretStorage and deleted the file watcher entirely — src/auth.ts now contains zero calls to createFileSystemWatcher. The settings file is read exactly once, for a one-time migration of an existing token into SecretStorage. With no watcher, the warning this PR silences can no longer happen.

The helper it added also already exists on main — reimplemented inline, and tested

The other half of this PR was src/auth-paths.ts, exporting a pure resolveDataHome(platform, env, homedir) so the cross-platform path derivation could be unit-tested away from the extension host.

main arrived at the same logic independently as getLegacySettingsPath() in src/auth.ts. The two are behaviourally equivalent: both read %LOCALAPPDATA% on Windows and $XDG_DATA_HOME elsewhere, and both fall back to ~/Library/Application Support on macOS and ~/.local/share on everything else. The only difference is the failure mode on Windows without %LOCALAPPDATA% — this PR throws, main returns undefined — and main's callers handle that.

It is covered too: test/auth.test.mts has resolves the legacy path under the data home. So merging this would add a second copy of logic that already exists and is already tested, plus a src/auth-paths.ts that nothing would import.

The PR is also in a conflicting state against main for exactly this reason: resolving it would mean re-adding the deleted watcher code. The underlying issue is fixed, so this is being closed rather than reworked.