fix: strip comments from the JSON body before sending it

[alanmdza]

Fixes #137.

Problem

A JSON body with // comments is sent as a quoted JSON string instead of an object. The same collection works in the desktop app and in the CLI, because both run the body through decomment first:

• packages/bruno-electron/src/ipc/network/prepare-request.js
• packages/bruno-cli/src/runner/prepare-request.js

So a collection authored in the desktop app — where JSON body comments have been supported since usebruno/bruno#396 — silently breaks when the same .bru files are run from VS Code. In our shared collection that was 80 of 127 requests with a JSON body. On a strict API it surfaces as a confusing validation error; ours (Django/DRF) answers Invalid data. Expected a dictionary, but got str.

Two places build the body here, and both have the bug:

1. getRequestData in ipc/network/index.ts — this is the one that runs for a normal send:

case 'json':
  return body.json || undefined;

The raw commented text becomes request.data. interpolateVars takes the string branch, and axios' stringifySafely cannot parse it, so it falls back to JSON.stringify(rawString) and the request goes out double-encoded. Its own doc comment says "Similar to bruno-cli's prepare-request.js" — which is exactly where the CLI applies decomment.

2. prepareBody in ipc/network/prepare-request.ts — reached when data is undefined:

try {
  return body.json ? JSON.parse(body.json) : undefined;
} catch {
  return body.json;      // still commented, so axios quotes it
}

Fix

decomment is not a dependency of this repo (script-runner.ts declares a local decomment that currently returns the script untouched), so rather than pulling the package in, this adds a small dependency-free helper: a JSON body has no regular expressions or template literals, so a string-aware scan is enough to tell a comment from a // that happens to live inside a value.

• getRequestData returns stripJsonComments(body.json) — same shape and type as before, just comment-free, mirroring decomment(request.body.json) in the CLI.
• prepareBody parses the stripped text, and falls back to the stripped text rather than to body.json. A body that mixes comments with unquoted variables ("quantity": {{qty}}) is still not valid JSON after stripping, so it takes that path; returning the raw text would hand interpolateVars a string that still contains // and the interpolated result would be quoted all the same. It also returns undefined for an empty body, so nothing is sent.

If you would rather match bruno-electron byte for byte by depending on decomment, swapping the helper is a one-line change — I kept it dependency-free to avoid touching the lockfile.

Tests

src/extension/ipc/network/prepare-request.spec.ts covers prepareBody with a line comment, a comment on its own line, a block comment, a // inside a string value, escaped quotes inside a value, the still-invalid fallback, an empty body, and the content-type default. (getRequestData is module-private, so it is not covered directly; happy to export it if you want a spec on it too.)

I verified the behaviour against the decomment that ships with the desktop app (4.1.0), comparing the body builder's output after variable interpolation and axios' stringifySafely rule; the two agree on every case except the ones that are invalid JSON in every client anyway, such as a trailing comma left behind by commenting a field out.

I also patched the shipped 5.0.2 bundle locally with the same change and confirmed against a real API that the request now arrives as an object.

---

Note: I used AI assistance to investigate and prepare this change.