Bit VS Code extension shows a false "untracked file dependencies" error with raw ANSI escape codes whenever a new file is added to a tracked component (reload clears it) #10697

I admit, I was frustrated (I'm just a human). After spending months figuring out low-level tooling issues and reporting them thoroughly, instead of writing my own code, I was greeted with 10-20 new issues after every update, along with a few old ones that you'd claimed were solved. Then I was told to report the new ones just as thoroughly, and that many clear regressions weren't regressions at all – even though they were. But proving that would have required spending even more days diving into your code.

And while I was doing all of this manually (with occasional help of free models), you were casually riding on top of the most cutting-edge AI available – one that could reproduce and solve all of it in hours at most, while I can't even afford it.

Of course, none of this is your fault – the fault is entirely mine. I'm just giving you my reasoning for why I had to step back and focus on my own code for a while. I've since improved my workarounds and patched the tooling locally to avoid dealing with constant bugs. I'll wait a few versions before I decide to update the pieces I'm currently using.

This report is a follow-up for: #10486

Environment

• VS Code 1.132
• Bit VS Code extension bit.vscode-bit-1.2.30
• Bit CLI 2.0.26 (newest, bvm)
• Windows

Problem

Every time a new file is added inside a tracked component's rootDir (e.g. projects/commonlib/components/my-check-box/my-check-box-changed-event-args.ts, imported from the component's index.ts / my-check-box.tsx), the PROBLEMS tab shows a spurious Error diagnostic with code UntrackedDependencies:

{
  "code": "UntrackedDependencies",
  "severity": 8,
  "message": "untracked file dependencies (use \"bit add <file>\" to track untracked files as components)\nindex.ts -> \u001b[33mprojects/commonlib/components/my-check-box/my-check-box-changed-event-args.ts\u001b[39m\nmy-check-box.tsx -> \u001b[33mprojects/commonlib/components/my-check-box/my-check-box-changed-event-args.ts\u001b[39m",
  "source": "bit"
}

Two distinct problems are visible in that one diagnostic:

1. False positive. The file is physically inside a tracked component's rootDir, so it is part of that component (Bit tracks whole directories; there is no per-file registration step). The message is wrong, and reloading the VS Code window clears it.
2. Raw ANSI escape codes (\u001b[33m / \u001b[39m) leak into the message text.

Root Cause

False positive – stale snapshot in the bit-server

The extension does not spawn the CLI per call; it keeps a long-lived bit-server-forever process and calls POST /api/cli/mini-status with
{ showIssues: true, ignoreCircularDependencies: true } (bitClient.miniStatus / miniStatusOneComp). The server resolves every dependency file to a component via consumer.bitMap.getComponentIdByPath(path) (@teambit/legacy.bit-map), and that map is built only from the component.files snapshot present when the workspace was loaded (_populateAllPaths() creates one path -> component-id entry per tracked file). A file created afterwards is not in the snapshot:

• auto-detect-deps.processOneDepFile → getComponentIdByDepFile → getComponentIdByPath returns undefined → _pushToUntrackDependenciesIssues emits UntrackedDependencies listing the new file with { existing: false }; on the next run the same file is re-found and both copies are flipped to existing: true.
• Reloading resets the server (re-scan / reconnect), the new file is back in the component's file list, and the issue disappears. A fresh CLI (bit mini-status <comp> --show-issues) never reports it at all – verified live.

ANSI codes – chalk-colored dataAsString rendered verbatim

UntrackedDependencies.dataToString() (@teambit/component-issues) wraps every untracked path with existing: true in chalk.yellow(...), so dataAsString contains \u001b[33m...\u001b[39m. The extension builds the diagnostic as c.description + " (" + c.solution + ")\n" + c.dataAsString (statusProvider.showStatusIssues) and the tree tooltip from the same string – no ANSI stripping anywhere.

Proposed Fix

The extension should not display an UntrackedDependencies issue whose "untracked" file is physically inside a tracked component's rootDir (it is part of that component – Bit never exempts files inside a rootDir), and it must strip ANSI escape sequences from every dataAsString it renders (diagnostics and tooltips).

Ideally fix the server-side snapshot itself (rebuild the BitMap per-file index when files change while the server is running), but a robust client-side fix is:

• filter UntrackedDependencies issues by component rootDir containment at the single miniStatusOneComp choke point (feeds both the PROBLEMS tab and the status tree), and
• run a generic ANSI-CSI cleaner over dataAsString before rendering.

Local Fix / Workaround

A patch script (patch-bit-untracked-ansi.ps1) applies 4 byte-exact injections to the extension bundle out\extension.js (removable with -Unpatch, -DryRun previews):

1. Injects module-level bitStripAnsi(s) and bitFilterIssueList(issues, compPath).
2. miniStatusOneComp: issues:bitFilterIssueList(i.compWithIssues[0]?.issues||[],e).
3. showStatusIssues: message dataAsString wrapped in bitStripAnsi(...).
4. Tree tooltip dataAsString wrapped in bitStripAnsi(...).

bitFilterIssueList is fail-open: it only drops the whole issue when every untracked path is inside the active component's rootDir; missing/unknown data, other component ids, genuinely outside paths, or mixed cases are all kept, so real untracked dependencies are never hidden.

patch-bit-untracked-ansi.zip

Reproduction

1. In a Bit workspace (versioning disabled), open any tracked component, e.g. projects/commonlib/components/my-check-box.
2. Add a new file inside that component's folder (e.g. my-check-box-changed-event-args.ts) and import it from that component's files.
3. Observed: the PROBLEMS tab immediately shows the Error above (with \u001b[33m in the message); the path is always the new file.
4. Reload the window: the diagnostic is gone and bit status / bit mini-status show no such issue.
5. Expected: no diagnostic for a file that is part of the component, and no ANSI escape sequences in any diagnostic/tooltip text.

Afterword:

If my efforts have saved you significant time and effort in resolving issues within your project, I'd kindly ask you to consider supporting future open-source work through inference donations:

• DIEM and VVV donations on Base will fund ongoing, daily inference on Venice, dedicated exclusively to addressing public issues in open-source projects.
• Donations in any other EVM-compatible currency will be converted to one-time inference credits at current API rates on PPQ or Venice, and used for the same purpose.

0x5efCEfb9Aa676E580434dEb7FB118845B233E04a