What this does

I've added support for comments in the JSON editor :) ! Now you can use // and /* */ style comments when writing request bodies, which makes it way easier to document what you're testing.

Why I built this

This was something I was really missing when I started using Yaak. I write multiple comments in my HTTP requests to test things, and I can't live without them. When I found out Yaak doesn't support this, I decided to add it myself. I thought it would be kinda easy, but it took me some time to get it right - though it was a really enjoyable experience XD.

When I'm working with complex API requests, I often want to add notes about what certain fields do or remind myself to change something later. Before this PR, adding comments would break everything because they're not valid JSON. This PR fixes that by:

• Stripping out comments before sending the actual HTTP request.
• Making the linter ignore comments so you don't get false errors.
• Highlighting comments in gray so they're easy to spot.

What changed

• Comments get removed automatically before requests are sent.
• Added visual styling so comments look different from regular code.
• The JSON validator won't complain about comments anymore.
• You can use Cmd/Ctrl+/ to quickly comment/uncomment lines.

Example

Now this works without errors:

{
  "userId": 123,  // testing with user from staging
  "action": "login",
  /* 
    TODO: need to add email field here
    once the API is updated
  */
  "remember": true
}

The comments stay in the editor but get stripped out when the request is actually sent, so the API only sees valid JSON.

Tested

• Comments don't break HTTP requests anymore
• Both // and /* */ styles work
• Linter still catches real JSON errors
• Keyboard shortcut works as expecte

Future improvements

There's one edge case with the highlighting: if you have // /* on a line, the multi-line comment won't actually work (because the /* is inside a single-line comment), but the highlighting will still show everything after it as commented. Ideally, the highlighting should stop so the user can see that something's wrong. Although users can see a red dot and error indicator showing there's a problem, the visual highlighting could be clearer. I don't think this is critical for now since it's a rare case, but it could be improved in a future PR to help catch these mistakes.

Current behavior (left) vs. Expected behavior (right):