DEV Community: 99Tools

Think your JSON is valid? Think again. 🚨 From trailing commas to invalid data types, these are the 10 JSON mistakes developers hit most often—and the exact fixes to avoid hours of debugging. Save this guide for your next API project. 👇

99Tools — Tue, 09 Jun 2026 04:29:48 +0000

99Tools

Jun 8

10 JSON Errors Every Developer Hits (And Exactly How to Fix Them)

#json #webdev #javascript #programming

11 min read

10 JSON Errors Every Developer Hits (And Exactly How to Fix Them)

99Tools — Mon, 08 Jun 2026 12:31:32 +0000

JSON looks simple — just key-value pairs, right? But its strictness is legendary. No trailing commas. No comments. No single quotes. No undefined. Miss one rule and your entire payload is dead on arrival.

Even senior developers get caught by these. Not because they don't know JSON — because the spec is unforgiving in ways that feel arbitrary until you understand why those rules exist.

This article covers the 10 most common JSON errors, why they happen, and exactly how to fix them — with real-world code examples, not toy snippets.

Quick Reference Table

#	Error	The Fix
1	Trailing commas	Remove the last comma in arrays/objects
2	Single quotes	Use double quotes `"` for all keys and values
3	`undefined` / `NaN` / `Infinity`	Replace with `null` or a valid number
4	Unescaped special characters	Escape `"`, `\`, and control chars in strings
5	Mismatched brackets	Lint your JSON before sending
6	Comments in JSON	Strip comments; use JSON5 if you need them
7	Wrong data types	Validate types at the boundary — never silently coerce
8	Circular references	Use a replacer function or the `flatted` library
9	Date objects	Store as ISO strings; parse explicitly on the way out
10	Large integers	Use strings or `BigInt` for numbers > 2⁵³ − 1

Why Does JSON Keep Tripping Developers Up?

JSON was designed as a minimal, language-agnostic data format. That minimalism is intentional — but it means there's almost zero forgiveness baked in.

Unlike JavaScript (which has semicolon insertion, loose equality, and other guardrails), JSON has zero tolerance for syntax deviations.

The other issue: most JSON errors surface at runtime — often in production, often deep inside a third-party API response you didn't write. Editor linting helps, but it can't catch errors in dynamically generated payloads.

That's what this guide is for.

Error #1: Trailing Commas That Kill Your Parser

What's happening

A trailing comma is a comma after the last item in an array or object. JavaScript has allowed this since ES5. JSON absolutely does not.

The error you'll see

SyntaxError: Unexpected token } in JSON at position 42

❌ Wrong

{
  "user": {
    "name": "Priya Kapoor",
    "role": "admin",
    "permissions": ["read", "write", "delete",]
  },
}

Two trailing commas here: after "delete" and after the closing } of user.

✅ Fixed

{
  "user": {
    "name": "Priya Kapoor",
    "role": "admin",
    "permissions": ["read", "write", "delete"]
  }
}

Remove the last comma from every array and object. Most JSON linters flag this instantly.

💡 Pro tip: Never hand-edit minified JSON. Always pretty-print first (JSON.stringify(obj, null, 2)), edit, then re-minify. The structure is visible and trailing commas are easy to catch.

Error #2: Single Quotes Instead of Double Quotes

What's happening

JavaScript lets you use single quotes, double quotes, or backticks for strings. JSON only allows double quotes — for both keys and string values.

The error you'll see

SyntaxError: Unexpected token ' in JSON at position 0

❌ Wrong

{
  'endpoint': '/api/v2/orders',
  'timeout': '30s'
}

✅ Fixed

{
  "endpoint": "/api/v2/orders",
  "timeout": "30s"
}

The sneaky variant

This bites developers who copy a JavaScript object literal and paste it into a JSON file:

// Valid JS object literal
const config = {
  host: 'localhost',
  port: 5432
}

That object has unquoted keys — which is also invalid JSON, even if you swap in double quotes. Both the key format and the string delimiters need to change.

💡 Pro tip: If you accept JSON from users or external systems, always wrap JSON.parse() in a try/catch. Never assume the format is correct.

Error #3: `undefined`, `NaN`, and `Infinity` Aren't Valid JSON

What's happening

JavaScript has special values — undefined, NaN, Infinity, -Infinity — that simply don't exist in the JSON spec. When you serialize an object containing these, JSON.stringify() silently drops or converts them.

The error you'll see

No error. That's the problem. The values just vanish silently.

const payload = {
  userId: 42,
  score: NaN,
  bonus: Infinity,
  metadata: undefined
};

console.log(JSON.stringify(payload));
// {"userId":42,"score":null,"bonus":null}
// ⚠️ metadata key is gone entirely

❌ Wrong

const stats = {
  avgResponseTime: totalTime / requestCount, // 💥 NaN if requestCount === 0
  maxRetries: Infinity
};

fetch('/api/stats', {
  method: 'POST',
  body: JSON.stringify(stats)
});
// Server receives: {"avgResponseTime":null,"maxRetries":null}

✅ Fixed

function sanitizeForJSON(value) {
  if (typeof value !== 'number') return value;
  if (Number.isNaN(value) || !Number.isFinite(value)) return null;
  return value;
}

const stats = {
  avgResponseTime: sanitizeForJSON(totalTime / requestCount) ?? 0,
  maxRetries: 100 // Use a real cap, not Infinity
};

Or use a replacer with JSON.stringify:

const safeStringify = (obj) =>
  JSON.stringify(obj, (key, value) => {
    if (typeof value === 'number' && !Number.isFinite(value)) return null;
    if (value === undefined) return null;
    return value;
  });

💡 Pro tip: JSON.stringify also silently drops functions and Symbol values. If your object might contain these, validate the output or use a schema validator like zod or ajv before sending.

Error #4: Unescaped Special Characters in Strings

What's happening

Certain characters inside JSON strings must be escaped with a backslash. The most common culprits: double quotes, backslashes, and control characters like newlines and tabs.

The error you'll see

SyntaxError: Bad escaped character in JSON at position 34

Or a subtler one — a string that ends prematurely because an unescaped " closes it early.

❌ Wrong

{
  "message": "He said "hello" and left",
  "filePath": "C:\Users\priya\documents\report.pdf",
  "notes": "First line
Second line"
}

Three problems here:

Unescaped " inside a string
Unescaped backslashes in the Windows path
Literal newline inside a string

✅ Fixed

{
  "message": "He said \"hello\" and left",
  "filePath": "C:\\Users\\priya\\documents\\report.pdf",
  "notes": "First line\nSecond line"
}

Full escape reference:

Character	Escaped
`"`	`\"`
`\`	`\\`
Newline	`\n`
Tab	`\t`
Carriage return	`\r`
Unicode	`\uXXXX`

The golden rule for dynamic JSON

If you're building JSON strings from user input, always use JSON.stringify() — never concatenate strings manually:

// ❌ Never do this — JSON injection + XSS risk
const json = `{"message": "${userInput}"}`;

// ✅ Do this
const json = JSON.stringify({ message: userInput });

💡 Pro tip: Windows file paths are the #1 source of unescaped backslash bugs. If you're storing paths in JSON config files, always double-escape them or use forward slashes — Windows accepts both.

Error #5: Mismatched Brackets or Braces

What's happening

Every { needs a }. Every [ needs a ]. In long or deeply nested JSON, a missing bracket is easy to introduce and hard to spot manually.

The error you'll see

SyntaxError: Unexpected end of JSON input

SyntaxError: Expected ',' or '}' after property value in JSON at position 312

❌ Wrong

{
  "pipeline": {
    "stages": [
      {
        "name": "build",
        "steps": ["install", "compile", "test"
      },
      {
        "name": "deploy",
        "steps": ["push", "restart"]
      }
    ]
  }
}

The steps array in the first stage is missing its closing ].

✅ Fixed

{
  "pipeline": {
    "stages": [
      {
        "name": "build",
        "steps": ["install", "compile", "test"]
      },
      {
        "name": "deploy",
        "steps": ["push", "restart"]
      }
    ]
  }
}

How to find it fast

Paste your JSON into an online JSON formatter — it highlights exactly which line the error is on and pretty-prints your JSON so the structure is obvious. You can also run a quick check in Node:

node -e "JSON.parse(require('fs').readFileSync('config.json', 'utf8'))" && echo "Valid"

Or use jq:

cat data.json | jq .

💡 Pro tip: When writing large JSON by hand, add both the opening and closing bracket before filling in the contents. Same principle as closing HTML tags immediately — far less error-prone than adding the closer after 30 lines of content.

Error #6: Comments in JSON — The Feature That Doesn't Exist

What's happening

Developers coming from JavaScript, Python, or YAML naturally try to add comments to JSON config files. JSON has no comment syntax. None. Not //, not /* */, not #.

The error you'll see

SyntaxError: Unexpected token / in JSON at position 2

❌ Wrong

{
  // Database connection settings
  "host": "db.internal.example.com",
  "port": 5432, /* default Postgres port */
  "poolSize": 10 # max concurrent connections
}

✅ Fix option 1: Remove comments

{
  "host": "db.internal.example.com",
  "port": 5432,
  "poolSize": 10
}

✅ Fix option 2: Use a `_comment` convention

Some teams use a dedicated key for inline documentation:

{
  "_comment": "Database settings — see runbook for rotation procedure",
  "host": "db.internal.example.com",
  "port": 5432,
  "poolSize": 10
}

Not elegant, but it parses cleanly and is searchable.

✅ Fix option 3: Switch to JSON5 or JSONC

If you control the parsing (e.g., a config file for your own tool), use JSON5 or JSONC:

import JSON5 from 'json5';

const config = JSON5.parse(`{
  // Database connection
  host: "db.internal.example.com",
  port: 5432,
}`);

💡 Pro tip: tsconfig.json, .eslintrc.json, and VS Code's settings.json all silently support comments even though they use .json — VS Code's parser strips them. Don't let this fool you into thinking regular JSON.parse() handles them. It won't.

Error #7: Incorrect Data Types Causing Silent Failures

What's happening

JSON supports six types: strings, numbers, booleans, arrays, objects, and null. The problem isn't usually an invalid type — it's passing the right value in the wrong type, especially numbers as strings or booleans as strings.

The error you'll see

No parsing error at all. You get a logic bug — comparisons fail, math returns NaN, or an API returns a cryptic 400 Bad Request.

❌ Wrong

// HTML form data — everything comes back as strings
const formData = {
  userId: "1042",      // Should be a number
  isAdmin: "false",    // Should be a boolean — but "false" is truthy!
  retryCount: "3"      // Should be a number
};

// On the receiving end:
if (data.isAdmin) {
  // "false" is a non-empty string → truthy → this ALWAYS runs!
  grantAdminAccess(data.userId); // 💥 Security bug
}

✅ Fixed

const formData = {
  userId: parseInt(form.userId.value, 10),
  isAdmin: form.isAdmin.checked,  // boolean from checkbox
  retryCount: Number(form.retryCount.value)
};

Or validate and coerce at the boundary with zod:

import { z } from 'zod';

const UserSchema = z.object({
  userId: z.coerce.number().int().positive(),
  isAdmin: z.boolean(),
  retryCount: z.coerce.number().int().min(0).max(10)
});

const parsed = UserSchema.parse(rawFormData);
// Throws a detailed error if types don't match after coercion

💡 Pro tip: The "false" string bug is particularly dangerous. In JavaScript, every non-empty string is truthy — if ("false") evaluates to true. Always use strict boolean types when the value will be used in a conditional.

Error #8: Circular References When Serializing Objects

What's happening

A circular reference is when an object contains a reference back to itself (directly or through a chain). JSON.stringify() throws immediately when it encounters one.

The error you'll see

TypeError: Converting circular structure to JSON
    --> starting at object with constructor 'Object'
    |     property 'parent' -> object with constructor 'Object'
    --- property 'child' closes the circle

How it happens in the wild

const order = {
  id: "ORD-9821",
  customer: { name: "Alex Mensah" }
};

order.self = order; // Circular reference!
JSON.stringify(order); // 💥 TypeError

DOM nodes, Express req/res objects, and Sequelize/Mongoose model instances are full of these.

✅ Fix option 1: Use a replacer to skip circular refs

function safeStringify(obj) {
  const seen = new WeakSet();
  return JSON.stringify(obj, (key, value) => {
    if (typeof value === 'object' && value !== null) {
      if (seen.has(value)) return '[Circular]';
      seen.add(value);
    }
    return value;
  });
}

console.log(safeStringify(order));
// {"id":"ORD-9821","customer":{...},"self":"[Circular]"}

✅ Fix option 2: Use the `flatted` library for full round-trip support

import { stringify, parse } from 'flatted';

const json = stringify(order);   // Handles circular refs
const restored = parse(json);    // Restores the circular structure

✅ Fix option 3: Serialize only what you need

// Instead of serializing the whole ORM instance:
const orderForAPI = {
  id: order.id,
  customerName: order.customer.name,
  items: order.items.map(i => ({ sku: i.sku, qty: i.quantity }))
};

JSON.stringify(orderForAPI); // Clean, no circular refs

💡 Pro tip: This error is extremely common when logging Express request objects in error handlers. Never do logger.info(JSON.stringify(req)). Log req.method, req.url, req.headers, and req.body individually instead.

Error #9: Date Objects — The Serialization Trap

What's happening

JSON.stringify() converts Date objects to ISO 8601 strings automatically. But JSON.parse() does not convert them back. You get a plain string — silently, every time.

The error you'll see

No error at parse time. But later:

const event = JSON.parse(JSON.stringify({ createdAt: new Date() }));

console.log(typeof event.createdAt);    // "string" — not a Date!
console.log(event.createdAt.getTime()); // TypeError: event.createdAt.getTime is not a function

❌ Wrong pattern

const meeting = {
  title: "Sprint Planning",
  scheduledAt: new Date("2025-06-10T09:00:00Z"),
  duration: 60
};

const stored = JSON.stringify(meeting);
const restored = JSON.parse(stored);

// This silently fails — string vs number comparison is NaN
if (restored.scheduledAt > Date.now()) {
  sendReminder(); // Never called
}

✅ Fixed

const restored = JSON.parse(stored);

// Option 1: Parse manually
restored.scheduledAt = new Date(restored.scheduledAt);

// Option 2: Use a reviver function
const restoredSafe = JSON.parse(stored, (key, value) => {
  if (typeof value === 'string' && /^\d{4}-\d{2}-\d{2}T/.test(value)) {
    return new Date(value);
  }
  return value;
});

// Option 3: Use date-fns
import { parseISO } from 'date-fns';
const scheduledAt = parseISO(restored.scheduledAt);

💡 Pro tip: The cleanest architecture is to never store Date objects in state that crosses a serialization boundary. Use ISO strings throughout your app and only convert to Date when you actually need .getTime(), .toLocaleString(), etc.

Error #10: Large Integers and Precision Loss

What's happening

JavaScript uses 64-bit floating point (IEEE 754) for all numbers. The maximum safe integer is 2⁵³ − 1 (Number.MAX_SAFE_INTEGER = 9007199254740991). Any integer larger than this cannot be represented exactly — and JSON parsing silently rounds it.

The error you'll see

No error. Just silently wrong data:

const response = `{"id": 9007199254740993, "userId": 92233720368547758}`;

const parsed = JSON.parse(response);
console.log(parsed.id);     // 9007199254740992 — off by 1!
console.log(parsed.userId); // 92233720368547760 — completely wrong!

This is a real problem with PostgreSQL 64-bit IDs, Twitter/X Snowflake IDs, and distributed systems.

✅ Fix option 1: Use strings for large IDs

The Twitter/X API famously added an id_str field alongside id for this exact reason:

{
  "id": 9007199254740993,
  "id_str": "9007199254740993",
  "text": "JSON precision bugs are the worst"
}

Always use id_str in client code.

✅ Fix option 2: Pre-process with a regex before parsing

function parseBigInts(jsonString) {
  return JSON.parse(
    jsonString.replace(
      /(":\s*)(-?\d{17,})/g,
      (_, prefix, num) => `${prefix}"${num}"`
    )
  );
}

const safe = parseBigInts(`{"snowflakeId": 927349827349827349}`);
console.log(safe.snowflakeId); // "927349827349827349" — exact string

✅ Fix option 3: Use the `json-bigint` library

import JSONBig from 'json-bigint';

const parsed = JSONBig.parse(`{"id": 9007199254740993}`);
console.log(parsed.id); // 9007199254740993n — a real BigInt

💡 Pro tip: This bug only manifests for IDs large enough to exceed MAX_SAFE_INTEGER. Your test data (IDs like 1, 42, 1001) will never trigger it. It only hits in production. Always verify your ID generation strategy before assuming small numbers.

Debugging Toolkit

When you're staring at a broken JSON payload, here's your workflow:

1. Validate in Node

node -e "JSON.parse(require('fs').readFileSync('config.json', 'utf8'))" && echo "Valid"

2. Pretty-print with Python (no dependencies)

echo '{"a":1,"b":[1,2,3]}' | python3 -m json.tool

3. Validate + query with jq

cat data.json | jq .

4. Validate in your CI/CD pipeline

# In your package.json scripts:
"validate:config": "node -e \"JSON.parse(require('fs').readFileSync('./config.json'))\"",

Quick Reference Cheat Sheet

JSON CHEAT SHEET
══════════════════════════════════════════════════════════════

  SYNTAX RULES                      VALID TYPES
  ─────────────────────────────     ───────────────────────
  ✅ Double quotes only             String:   "hello"
  ✅ No trailing commas             Number:   42, 3.14
  ✅ No comments                    Boolean:  true, false
  ✅ Balanced brackets/braces       Null:     null
  ✅ Keys must be strings           Array:    [1, 2, 3]
                                    Object:   {"k": "v"}

  INVALID VALUES (use null instead)
  ─────────────────────────────────
  ❌ undefined   ❌ NaN   ❌ Infinity   ❌ Functions

  ESCAPE SEQUENCES IN STRINGS
  ─────────────────────────────────
  \"  →  "       \\  →  \       \n  →  newline
  \t  →  tab     \r  →  carriage return
  \uXXXX  →  Unicode character

  SPECIAL CASES TO WATCH FOR
  ─────────────────────────────────
  • Dates        → Store as ISO strings; parse explicitly
  • Big ints     → Use strings for IDs > 9007199254740991
  • Circular refs → Use replacer or flatted library
  • Type coercion → "false" ≠ false; "3" ≠ 3

══════════════════════════════════════════════════════════════

Wrapping Up

JSON errors almost always fall into one of two camps:

Syntax errors — trailing commas, wrong quotes, missing brackets. These are the easiest to fix. A good linter catches them before you run a single line of code. Add JSON validation to your editor, run JSON.parse() inside try/catch everywhere you accept external data.
Semantic traps — Dates that lose their type, integers that lose precision, undefined that silently vanishes. These are trickier because they don't throw errors — they silently corrupt your data. The fix is validation at the boundary using zod, ajv, or even a careful manual check before you trust the output of JSON.parse().

The patterns that burn developers the most are #3 (NaN/undefined disappearing silently), #9 (Dates becoming strings), and #10 (large integers rounding). If you add nothing else to your workflow, add a JSON schema validator at every API boundary.

Which of these has bitten you hardest? My personal nemesis is #9 — every single time. Drop the error number in the comments.

FAQ Schema Markup Generators: What They Actually Do (and What They Don't Tell You)

99Tools — Sat, 23 May 2026 09:09:33 +0000

So you've heard that adding FAQ schema to your pages can get you those sweet rich results in Google Search — the expandable Q&A dropdowns right in the SERP. You Google "FAQ schema generator", paste in your questions, copy the JSON-LD, and drop it in your <head>. Done, right?

Sort of. There's more going on here than most tutorials explain.

Let's break it down properly.

What Is FAQ Schema, Actually?

FAQ schema is a type of structured data — machine-readable metadata you embed in your HTML to tell search engines what kind of content is on your page.

It uses the schema.org/FAQPage vocabulary and is typically written in JSON-LD (JavaScript Object Notation for Linked Data), which Google officially recommends over Microdata or RDFa for new implementations.

A minimal, valid FAQ schema block looks like this:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "What is structured data?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Structured data is a standardized format for providing information about a page and classifying the page content."
      }
    }
  ]
}
</script>

The mainEntity array holds your questions. Each item is a Question with a name (the question text) and an acceptedAnswer containing an Answer with a text property.

That's the whole spec for this type. Not complicated — which is exactly why generators exist.

What Do FAQ Schema Generators Actually Do?

A FAQ Schema generator is just a UI wrapper around a template. You fill in fields, it writes the JSON-LD for you. Nothing more.

The output of every single FAQ schema generator in existence looks like the block above. They differ only in:

Whether they let you add multiple Q&A pairs (most do)
Whether the text field allows HTML (more on this in a second)
Whether they validate the output before showing it to you
Whether they minify or pretty-print the JSON

They do not:

Check if your questions match actual content on your page
Verify whether your page is eligible for rich results
Guarantee you'll get a rich snippet
Update automatically if you change your FAQ content

That last point trips people up constantly.

The HTML-in-answers Question

Google's documentation says the text property of an Answer does support a limited subset of HTML — specifically: <a>, <b>, <br>, <em>, <i>, <li>, <ol>, <strong>, <ul>.

Some generators strip all HTML from the answer field. Some preserve it. Some encode it incorrectly (double-escaping & instead of &, breaking the output).

If your answers need links or lists inside them, test your generator's output manually. Paste the result into Google's Rich Results Test and inspect what it actually parses.

Common Mistakes the Generator Won't Catch

1. Schema that doesn't match your visible content

Google's guidelines are explicit: your structured data must reflect content that is visually present on the page. If you generate FAQ schema for questions that only exist in the JSON-LD and not in the actual HTML — that's a violation, and Google can apply a manual action to your site.

Don't use generators to add "bonus" FAQs that aren't rendered on the page.

2. Using FAQPage on pages that aren't really FAQ pages

FAQPage is for pages where the primary purpose is answering questions. Dropping FAQ schema on a product page, a blog post, or a homepage just because you have one accordion component at the bottom is a gray area that Google has increasingly penalized.

3. Duplicate FAQ schema across multiple pages

If you have the same FAQ block on 50 pages (common with CMS templates), search engines see it as low-quality repeated content in structured data. Each FAQ schema implementation should be page-specific.

4. Stale schema after content edits

You updated the FAQ section on your page, but the JSON-LD in the <head> still has the old questions. Now your schema and your content disagree. Generators produce static output — you're responsible for keeping it in sync.

The Right Way to Use a Generator

Think of generators as scaffolding tools, not end-to-end solutions. Here's a sane workflow:

Write your FAQ content on the page first. Real questions, real answers, visible in the HTML.
Use a generator to produce the initial JSON-LD from that content.
Validate the output using Google's Rich Results Test.
Embed it — either inline in a <script> tag or injected via your CMS/tag manager.
Tie it to your content update process so the schema stays in sync.

For anything more than a few static pages, consider templating the schema generation into your build pipeline or CMS rather than relying on a one-off generator.

Validating Your Output

Two tools worth bookmarking:

Google Rich Results Test — tests whether Google can parse your schema and whether your page is eligible for rich results
Schema.org Validator — validates against the schema.org spec directly, independent of Google's interpretation

These aren't interchangeable. Google's validator tells you what Google will do with your schema. The schema.org validator tells you if your markup is technically correct per the open standard. Run both.

When Rich Results Don't Appear (and It's Not the Generator's Fault)

Even perfectly valid FAQ schema doesn't guarantee a rich result. Google treats rich results as optional enhancements, not entitlements. Common reasons you won't see them:

The page doesn't have enough authority or trust signals yet
Google already shows a competitor's FAQ snippet for the same queries
The SERP layout for those queries doesn't include FAQ features (Google has been reducing FAQ rich results for high-authority sites since 2023)
The page was crawled but not yet re-indexed since you added the schema

Structured data is an input signal to Google's rendering pipeline. What comes out the other end is Google's decision.

TL;DR

Thing	What It Does	What It Doesn't Do
FAQ Schema Generator	Writes valid JSON-LD for you	Validates content match, guarantees rich results
JSON-LD in `<head>`	Makes schema parseable by crawlers	Make questions visible to users
Google Rich Results Test	Shows if schema is parseable	Guarantees SERP appearance
FAQPage schema type	Signals Q&A structure to search engines	Work on pages without actual FAQ content

Structured data is one of those areas where the tooling is simple but the judgment required to use it correctly is non-trivial. Generators handle the syntax. Understanding when and how to apply the schema — that part is still on you.

Stop Writing Ugly SQL: A Developer's Guide to Clean, Readable Queries

99Tools — Tue, 19 May 2026 13:35:04 +0000

We've all been there. You open a PR, and the SQL query looks like someone sneezed on the keyboard:

select u.id,u.name,u.email,o.total,o.created_at from users u join orders o on u.id=o.user_id where o.status='completed' and o.created_at >= '2024-01-01' order by o.created_at desc limit 50

It works. It returns the right data. But it's a nightmare to review, debug, or extend.

SQL readability is not a cosmetic concern — it's an engineering discipline. Messy SQL leads to logic errors, missed optimizations, and silent bugs that survive code review because nobody wants to untangle the mess.

This guide walks through the conventions, habits, and formatting rules that make SQL a joy to work with.

Why SQL Formatting Matters More Than You Think

Unlike application code, SQL queries often live in multiple places simultaneously — inside ORM raw query methods, migration files, stored procedures, BI tools, and debug logs. A single ugly query might be read by:

A backend engineer debugging a slow endpoint
A DBA optimizing an index
A data analyst trying to understand business logic
You, six months from now, at 11pm before a deploy

Consistent formatting makes all of these scenarios less painful.

The Core Rules

1. Capitalize SQL keywords

SQL keywords should be uppercase. Column names, table names, and aliases should be lowercase (or match your schema's convention).

Bad:

select id, name from users where active = true

Good:

SELECT id, name
FROM users
WHERE active = true

This instantly distinguishes SQL structure from your data model.

2. One clause per line

Every major clause — SELECT, FROM, JOIN, WHERE, GROUP BY, HAVING, ORDER BY, LIMIT — gets its own line. No exceptions.

Bad:

SELECT u.id, u.name, COUNT(o.id) AS order_count FROM users u LEFT JOIN orders o ON u.id = o.user_id WHERE u.created_at >= '2023-01-01' GROUP BY u.id, u.name HAVING COUNT(o.id) > 5 ORDER BY order_count DESC

Good:

SELECT
    u.id,
    u.name,
    COUNT(o.id) AS order_count
FROM users u
LEFT JOIN orders o ON u.id = o.user_id
WHERE u.created_at >= '2023-01-01'
GROUP BY
    u.id,
    u.name
HAVING COUNT(o.id) > 5
ORDER BY order_count DESC

The second version can be scanned in seconds. The first requires active decoding.

3. Align your columns in the SELECT list

Put each selected column on its own line, indented consistently (2 or 4 spaces — pick one and stick to it):

SELECT
    account_id,
    account_name,
    region,
    plan_type,
    created_at
FROM accounts
WHERE status = 'active'

This makes it trivial to add, remove, or reorder columns during development.

4. Qualify every column name in joins

Once you have more than one table in a query, always prefix columns with their table alias. Never leave a reader guessing which table id or created_at belongs to.

Ambiguous:

SELECT id, name, total, created_at
FROM users
JOIN orders ON users.id = orders.user_id

Clear:

SELECT
    u.id,
    u.name,
    o.total,
    o.created_at
FROM users u
JOIN orders o ON u.id = o.user_id

This also protects you when schema changes add a new column with a conflicting name — your query won't silently start returning the wrong data.

5. Write meaningful aliases

Single-letter aliases like a, b, x are lazy and harmful. Use short but meaningful abbreviations.

-- Bad
SELECT a.name, b.total
FROM accounts a
JOIN invoices b ON a.id = b.account_id

-- Good
SELECT acc.name, inv.total
FROM accounts acc
JOIN invoices inv ON acc.id = inv.account_id

6. Put JOIN conditions on a separate, indented line (for complex joins)

When join conditions are multi-part or involve expressions, break them out clearly:

SELECT
    p.id,
    p.title,
    c.body AS latest_comment
FROM posts p
LEFT JOIN comments c
    ON c.post_id = p.id
    AND c.created_at = (
        SELECT MAX(created_at)
        FROM comments
        WHERE post_id = p.id
    )
WHERE p.published = true

7. Use CTEs to break up complexity

Common Table Expressions (CTEs) are one of the most underused tools in SQL. Instead of nesting subqueries three levels deep, break the logic into named, readable steps.

Subquery hell:

SELECT avg_revenue, cohort
FROM (
    SELECT cohort, AVG(revenue) AS avg_revenue
    FROM (
        SELECT
            DATE_TRUNC('month', first_purchase_date) AS cohort,
            SUM(order_total) AS revenue
        FROM (
            SELECT u.id, MIN(o.created_at) AS first_purchase_date, o.total AS order_total
            FROM users u
            JOIN orders o ON u.id = o.user_id
            GROUP BY u.id, o.total
        ) user_orders
        GROUP BY cohort
    ) cohort_revenue
    GROUP BY cohort
) final
ORDER BY cohort

CTE version:

WITH user_first_purchase AS (
    SELECT
        u.id AS user_id,
        MIN(o.created_at) AS first_purchase_date
    FROM users u
    JOIN orders o ON u.id = o.user_id
    GROUP BY u.id
),

cohort_revenue AS (
    SELECT
        DATE_TRUNC('month', ufp.first_purchase_date) AS cohort,
        SUM(o.total) AS revenue
    FROM user_first_purchase ufp
    JOIN orders o ON ufp.user_id = o.user_id
    GROUP BY cohort
),

cohort_averages AS (
    SELECT
        cohort,
        AVG(revenue) AS avg_revenue
    FROM cohort_revenue
    GROUP BY cohort
)

SELECT
    cohort,
    avg_revenue
FROM cohort_averages
ORDER BY cohort

The CTE version is longer but infinitely more debuggable. You can run each CTE independently to validate intermediate results. This matters enormously in production debugging.

8. Comment non-obvious logic

SQL is often used for business logic that isn't apparent from the data alone. Comment that context directly in the query.

SELECT
    customer_id,
    SUM(order_total) AS lifetime_value
FROM orders
WHERE
    -- Exclude test orders created by the QA team's shared account
    customer_id != 9999
    -- Only count orders after the platform migration (older data is unreliable)
    AND created_at >= '2022-06-01'
GROUP BY customer_id
HAVING SUM(order_total) > 0

Future you will be grateful.

Refactoring a Real Query: Before and After

Here's a realistic before/after from a production analytics query:

Before:

select u.id,count(distinct s.id) as sessions,count(distinct e.id) as events,max(s.started_at) as last_seen from users u left join sessions s on s.user_id=u.id and s.started_at>now()-interval '30 days' left join events e on e.session_id=s.id and e.type not in ('pageview','heartbeat') where u.plan='pro' and u.deleted_at is null group by u.id having count(distinct s.id)>0 order by sessions desc limit 100

After:

SELECT
    u.id,
    COUNT(DISTINCT s.id)  AS sessions,
    COUNT(DISTINCT e.id)  AS events,
    MAX(s.started_at)     AS last_seen
FROM users u
LEFT JOIN sessions s
    ON s.user_id = u.id
    AND s.started_at > NOW() - INTERVAL '30 days'
LEFT JOIN events e
    ON e.session_id = s.id
    -- Exclude low-signal event types from engagement count
    AND e.type NOT IN ('pageview', 'heartbeat')
WHERE
    u.plan = 'pro'
    AND u.deleted_at IS NULL
GROUP BY u.id
HAVING COUNT(DISTINCT s.id) > 0
ORDER BY sessions DESC
LIMIT 100

Same query. Completely different readability. The second version makes the intent, filters, and join logic obvious at a glance.

Tooling: Format First, Then Review

If you're working with legacy SQL or reviewing someone else's query, formatting it first before reading it is one of the highest-ROI habits you can build. A well-formatted query reveals its structure — and its bugs.

For quick formatting without leaving your browser, this SQL formatter handles most SQL dialects and produces consistently indented, readable output in one click. It's especially useful when you inherit a minified query from a log file or a BI tool export and need to understand it quickly.

For integrating formatting into your dev workflow, the sql-formatter npm package is excellent — it supports PostgreSQL, MySQL, SQLite, BigQuery, and more, and you can hook it into Prettier or a pre-commit check.

Conventions Worth Standardizing Across Your Team

If you're working in a team, agree on these and write them down:

Convention	Recommended Default
Keyword casing	`UPPERCASE`
Identifier casing	`snake_case` (match your schema)
Indentation	4 spaces
Alias style	Short abbreviation, not single letter
Column per line	Always in `SELECT` with 3+ columns
CTE preference	Always over 2+ levels of subquery nesting

Enforcing these via a linter (e.g. SQLFluff) rather than hoping for consistency is even better — SQLFluff supports dozens of dialects and integrates with CI pipelines cleanly.

Quick Reference Cheat Sheet

-- ✅ Correct structure
WITH cte_name AS (
    SELECT
        column_one,
        column_two,
        column_three
    FROM table_name tn
    JOIN other_table ot ON tn.id = ot.table_id
    WHERE tn.some_condition = true
)

SELECT
    c.column_one,
    c.column_two,
    c.column_three,
    COUNT(t.id) AS related_count
FROM cte_name c
LEFT JOIN third_table t ON c.column_one = t.foreign_key
GROUP BY
    c.column_one,
    c.column_two,
    c.column_three
ORDER BY c.column_one ASC
LIMIT 1000

Final Thoughts

SQL style isn't about personal preference — it's about the next person (including yourself) who has to read, debug, or extend your query under pressure. Clean SQL is a form of documentation.

The conventions here are not the only valid choices. What matters is consistency. Pick a style, document it, and automate enforcement where possible.

If you have conventions or habits that have saved you in production, drop them in the comments — I'd love to see what others have standardized.

Most devs send the whole object and call it a PATCH. RFC 6902 exists for a reason. Here's what JSON Patch actually does and when it's worth the switch.

99Tools — Mon, 11 May 2026 16:51:45 +0000

99Tools

May 11

Stop sending entire objects in your PATCH requests. There's a better way

#javascript #json #webdev #api

3 min read

Stop sending entire objects in your PATCH requests. There's a better way

99Tools — Mon, 11 May 2026 16:49:43 +0000

I'll be honest — I spent years writing PATCH endpoints that just took the whole object and merged it server-side. You probably have too. It works. Until it doesn't.

You get concurrent edits. You get race conditions. You get a client that sends { "role": null } because it forgot to exclude the field. And your "partial update" is silently nuking data.

Then I found RFC 6902 — JSON Patch. And it solved exactly this problem in a way I hadn't thought about.

What JSON Patch actually is

Instead of sending the new version of an object, you send a description of the changes. A list of operations: what to add, remove, replace, move.

Here's the difference in practice:

❌ The old way — send the whole thing

PATCH /users/42
Content-Type: application/json

{
  "name": "Alice",
  "email": "alice@example.com",
  "role": "admin",
  "preferences": {
    "theme": "dark",
    "notifications": true
  }
}

✅ With JSON Patch — send only what changed

PATCH /users/42
Content-Type: application/json-patch+json

[
  { "op": "replace", "path": "/role", "value": "admin" },
  { "op": "replace", "path": "/preferences/theme", "value": "dark" }
]

Two fields changed. Two operations. Nothing else touched.

The six operations

[
  { "op": "add",     "path": "/tags/0",    "value": "urgent"  },
  { "op": "remove",  "path": "/draft"                         },
  { "op": "replace", "path": "/status",    "value": "active"  },
  { "op": "move",    "from": "/tmp/name",  "path": "/name"    },
  { "op": "copy",    "from": "/template",  "path": "/doc"     },
  { "op": "test",    "path": "/version",   "value": 3         }
]

The test op is the one most people ignore. It fails the whole patch if the value at the path doesn't match — which gives you optimistic locking for free. If /version isn't 3, nothing gets applied. That's huge for concurrent edits.

A real-world scenario

Imagine a collaborative config editor. Two users open the same document. User A changes the timeout. User B changes the retry count. With a full-object PUT, whoever saves last wins and overwrites the other's change.

With JSON Patch + test:

[
  { "op": "test",    "path": "/version",  "value": 7    },
  { "op": "replace", "path": "/timeout",  "value": 5000 }
]

If someone else already committed and bumped the version to 8, this patch fails with a 409. The client knows to re-fetch and retry. Clean, explicit, auditable.

The diff problem — and how I handle it

The annoying part is writing patches by hand. When you're prototyping or debugging, you just want to paste two JSON states and see what changed.

The compare() output is exactly what a JSON Patch generator produces — a minimal array of ops describing the diff between two states. In production, you generate this programmatically. During prototyping, you're usually diffing by hand to understand what your code should be producing.

For production use, you don't write patches manually — you generate them programmatically from a diff.

Libraries worth knowing

For JavaScript/Node.js, fast-json-patch is the go-to:

import * as jsonpatch from 'fast-json-patch';

const before = { name: "Alice", role: "user" };
const after  = { name: "Alice", role: "admin" };

const patch = jsonpatch.compare(before, after);
// [{ op: "replace", path: "/role", value: "admin" }]

const result = jsonpatch.applyPatch(before, patch).newDocument;

For Python, jsonpatch works the same way — make_patch() to diff, apply() to execute.

Things that will bite you

JSON Pointer paths (RFC 6901) use / as separator. A key containing a slash or tilde must be escaped: ~ → ~0, / → ~1. This silently fails if you forget.
Array indices are fragile. /items/2 means the third element right now — if the array shifts between diff and apply, you're patching the wrong element. - as index means "append", which is usually safer.
Skip the test op and you lose the main concurrency benefit. It's optional in the spec, but you probably want it in any multi-user scenario.

When should you actually use this?

Honestly, not everything needs JSON Patch. If you're building a simple CRUD app with a single user, PATCH with a partial object is fine. JSON Patch earns its complexity when you have: concurrent editors, audit logs that need to record exactly what changed, sync protocols (think CRDTs, OT), or large objects where sending the whole thing is wasteful.

If any of those apply — it's worth the RFC read.

Are you using JSON Patch in production? I'm curious how people handle the array index fragility problem specifically — do you use stable IDs in your patch paths, or do you diff differently? Drop it in the comments 👇

Structured data is one of the most overlooked SEO advantages. While most developers focus on content and backlinks, schema markup helps search engines truly understand your pages — unlocking rich results, better visibility, and higher CTRs. 🚀

99Tools — Thu, 07 May 2026 04:09:32 +0000

99Tools

May 7

Structured Data Is the SEO Cheat Code Most Developers Ignore

#seo #webdev #html #beginners

4 min read

Structured Data Is the SEO Cheat Code Most Developers Ignore

99Tools — Thu, 07 May 2026 03:58:56 +0000

If you've ever wondered why some Google results show star ratings, prices, FAQs, or rich snippets — while yours just shows a plain blue link — the answer is usually structured data.

It's one of the highest-leverage SEO techniques available to developers, and it's almost entirely skipped in most beginner-to-intermediate SEO guides. Let's fix that.

What is structured data?

Structured data is machine-readable information you add to your HTML that tells search engines exactly what your page is about.

Think of it as a translation layer between your human-readable content and Google's crawlers. Instead of guessing that your page sells a product, Google knows — because you told it in a format it understands.

The most common format is JSON-LD (JavaScript Object Notation for Linked Data), and it lives in a <script> tag in your page's <head>:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Wireless Noise-Cancelling Headphones",
  "description": "Premium headphones with 30-hour battery life.",
  "brand": {
    "@type": "Brand",
    "name": "SoundMax"
  },
  "offers": {
    "@type": "Offer",
    "price": "149.99",
    "priceCurrency": "USD",
    "availability": "https://schema.org/InStock"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.7",
    "reviewCount": "318"
  }
}
</script>

Add that to a product page and you're giving Google the signal it needs to show a rich result with star ratings and price — right in the SERP.

Why developers should care (not just SEOs)

Most SEO advice is aimed at marketers. "Write better meta descriptions. Build backlinks. Post consistently."

Structured data is different — it's fundamentally a code problem. You need to:

Know the right Schema.org vocabulary
Write valid JSON-LD without syntax errors
Map the right properties to the right @type
Keep it in sync with your actual page content

This puts structured data squarely in developer territory. And if you're building anything with an e-commerce store, blog, local business page, recipe site, or any kind of product listing — you're leaving rich results on the table if you skip it.

The types that matter most

Schema.org has hundreds of types, but for most projects, these six cover 90% of use cases:

Type	What it unlocks
`Product`	Price, availability, star ratings in SERPs
`Article`	Headline, author, date in Google News/Discover
`FAQPage`	Expandable Q&A blocks directly in search results
`LocalBusiness`	Map pin, hours, phone number in Knowledge Panel
`BreadcrumbList`	Clean URL path shown in result snippet
`Review`	Rich stars for individual reviews

The catch: writing it by hand is error-prone

Here's where most developers get tripped up. JSON-LD looks simple, but the Schema.org vocabulary is sprawling, inconsistent across types, and easy to get subtly wrong — a missing required field, a wrong @type, a value in the wrong format.

Google's Rich Results Test will tell you if your markup is valid, but won't help you write it from scratch.

That's why I've been using a Product Schema Markup Generator — it lets you fill in your product details through a form and generates clean, valid JSON-LD that you can drop straight into your <head>. No documentation-diving, no typo-hunting. For product-heavy pages especially, it cuts the implementation time significantly.

Worth bookmarking if you're adding Product schema to any kind of store or catalogue page.

Validating your markup

Once you have your JSON-LD in place, always run it through:

Google's Rich Results Test — confirms eligibility for rich snippets
Schema.org Validator — checks structural correctness
Google Search Console → Enhancements — shows real-world errors after indexing

Common errors to watch for:

Missing required fields (e.g. offers is required for Product)
Wrong date format (must be ISO 8601: 2024-11-15)
ratingValue outside the 0–5 range without specifying bestRating

A practical implementation checklist

✅ Add JSON-LD in <head>, not inline or in body
✅ Use @context: "https://schema.org"
✅ Match @type to your content type precisely
✅ Ensure all values match what's visible on the page
✅ Validate with Rich Results Test before deploying
✅ Monitor Search Console for markup errors post-deploy

The compounding SEO benefit

Rich results don't directly boost your ranking — Google is clear on that. What they do is dramatically increase click-through rate (CTR). A result with star ratings and price snippets just looks more trustworthy and informative than a plain link.

Higher CTR → more traffic for the same ranking → Google starts to treat your page as more relevant → rankings improve over time.

It's one of the few truly compounding SEO wins that's entirely under your control as a developer.

Closing thought

Structured data is the rare intersection of "SEO best practice" and "concrete developer task." You can implement it, test it, and see results — unlike most SEO advice, which lives in the fog of "wait six months."

If you're building anything public-facing, add structured data to your project's definition of done. Future-you (and Google's crawler) will thank you.

Found this useful? Drop a ❤️ or share with a dev who's building product pages. Happy to answer questions in the comments about implementation specifics.

user_id vs userId is the bug that costs you an hour on Friday. 📉 Stop the manual hacks! Learn the "Boundary Rule" for clean code, recursive JS helpers, and type-safe TS. Clean code starts with consistency. 🚀

99Tools — Fri, 01 May 2026 09:39:08 +0000

99Tools

May 1

The Case for Case Conversion: A Developer's Guide to Consistent Text Casing

#webdev #programming #javascript #python

7 min read

Small JavaScript mistakes can break your entire app. Here are 5 common errors developers make—and how a simple validation step can save hours of debugging.

99Tools — Fri, 24 Apr 2026 09:45:24 +0000

99Tools

Apr 24

5 Mistakes Developers Make Without a JavaScript Validator

#programming #javascript #tutorial

3 min read

Stop squinting at messy terminal text! 😫 Switch to a visual workflow to validate and edit JSON with zero friction. 🚀 Boost your debugging speed now.

99Tools — Sun, 22 Feb 2026 16:34:11 +0000

Debugging APIs? Why a Visual JSON Editor is Better Than Your Terminal

99Tools ・ Feb 22

Debugging APIs? Why a Visual JSON Editor is Better Than Your Terminal

99Tools — Sun, 22 Feb 2026 16:30:39 +0000

Every developer has been there: you’re testing a new REST API endpoint, you run a curl command, and your terminal is suddenly flooded with a massive, unformatted wall of white text. You’re squinting at the screen, trying to find a specific user_id or checking if a boolean is true or false, only to realize you’ve missed a closing bracket three levels up.

While the terminal is the "purist" way to work, it isn't always the most efficient. When it comes to complex data structures, a Visual JSON Editor is a game-changer for your workflow. Here is why you should move your API debugging out of the CLI and into a dedicated visual tool.

1. Human-Readable Hierarchy (Tree View)

The biggest flaw of the terminal is its linear nature. Even with "pretty-print" flags, a 500-line JSON response requires endless scrolling.

A visual editor provides a Tree View, allowing you to collapse and expand nested objects. This lets you ignore the "noise" (like metadata or headers) and focus strictly on the data payload you are debugging.

2. Instant Syntax Validation

One missing comma or a stray quotation mark can break an entire integration. If you are manually tweaking a request body in a terminal-based editor like Nano or Vim, it’s easy to make a typo.

A dedicated tool allows you to validate and edit JSON in real-time. It highlights syntax errors immediately, saving you from the "Trial and Error" loop of sending a request, getting a 400 Bad Request error, and guessing where the syntax went wrong.

3. Data Type Clarity

Is that price a string ("19.99") or a number (19.99)? In a raw terminal output, the difference is just two tiny tick marks. In a visual JSON editor, different data types (Strings, Numbers, Booleans, Nulls) are usually color-coded. This visual distinction is crucial when debugging type-mismatch errors in your frontend code.

How to Optimize Your API Debugging Workflow

To get the most out of your API testing, follow this 3-step professional workflow:

The Fetch: Use your terminal or Postman to get the raw data from the API.

The Format: Paste that messy string into a Visual JSON Editor.

The Audit: Use the editor to validate and edit JSON structures, ensuring your keys match your documentation before you hard-code them into your application.

Why This Matters for Performance

Beyond just "looking nice," using a visual tool prevents cognitive fatigue. Developers spend roughly 50% of their time debugging. By using tools that visualize data structures, you reduce the mental load required to parse code, allowing you to find bugs faster and ship cleaner features.

Conclusion

The terminal is great for execution, but a visual editor is superior for inspection. If you're still hunting through white-on-black text for a nested API key, it’s time to upgrade your toolkit.

DEV Community: 99Tools

Think your JSON is valid? Think again. 🚨 From trailing commas to invalid data types, these are the 10 JSON mistakes developers hit most often—and the exact fixes to avoid hours of debugging. Save this guide for your next API project. 👇

10 JSON Errors Every Developer Hits (And Exactly How to Fix Them)

10 JSON Errors Every Developer Hits (And Exactly How to Fix Them)

Quick Reference Table

Why Does JSON Keep Tripping Developers Up?

Error #1: Trailing Commas That Kill Your Parser

What's happening

The error you'll see

❌ Wrong

✅ Fixed

Error #2: Single Quotes Instead of Double Quotes

What's happening

The error you'll see

❌ Wrong

✅ Fixed

The sneaky variant

Error #3: undefined, NaN, and Infinity Aren't Valid JSON

What's happening

The error you'll see

❌ Wrong

✅ Fixed

Error #4: Unescaped Special Characters in Strings

What's happening

The error you'll see

❌ Wrong

✅ Fixed

The golden rule for dynamic JSON

Error #5: Mismatched Brackets or Braces

What's happening

The error you'll see

❌ Wrong

✅ Fixed

How to find it fast

Error #6: Comments in JSON — The Feature That Doesn't Exist

What's happening

The error you'll see

❌ Wrong

✅ Fix option 1: Remove comments

✅ Fix option 2: Use a _comment convention

✅ Fix option 3: Switch to JSON5 or JSONC

Error #7: Incorrect Data Types Causing Silent Failures

What's happening

The error you'll see

❌ Wrong

✅ Fixed

Error #8: Circular References When Serializing Objects

What's happening

The error you'll see

How it happens in the wild

✅ Fix option 1: Use a replacer to skip circular refs

✅ Fix option 2: Use the flatted library for full round-trip support

✅ Fix option 3: Serialize only what you need

Error #9: Date Objects — The Serialization Trap

What's happening

The error you'll see

❌ Wrong pattern

✅ Fixed

Error #10: Large Integers and Precision Loss

What's happening

The error you'll see

✅ Fix option 1: Use strings for large IDs

✅ Fix option 2: Pre-process with a regex before parsing

✅ Fix option 3: Use the json-bigint library

Debugging Toolkit

Quick Reference Cheat Sheet

Wrapping Up

FAQ Schema Markup Generators: What They Actually Do (and What They Don't Tell You)

What Is FAQ Schema, Actually?

What Do FAQ Schema Generators Actually Do?

The HTML-in-answers Question

Common Mistakes the Generator Won't Catch

1. Schema that doesn't match your visible content

2. Using FAQPage on pages that aren't really FAQ pages

3. Duplicate FAQ schema across multiple pages

4. Stale schema after content edits

The Right Way to Use a Generator

Validating Your Output

When Rich Results Don't Appear (and It's Not the Generator's Fault)

TL;DR

Error #3: `undefined`, `NaN`, and `Infinity` Aren't Valid JSON

✅ Fix option 2: Use a `_comment` convention

✅ Fix option 2: Use the `flatted` library for full round-trip support

✅ Fix option 3: Use the `json-bigint` library