The JSON config files quietly breaking your JS build (and how to fix them)

Tommy — Fri, 12 Jun 2026 06:58:06 +0000

Half the "weird" build failures in a JavaScript/TypeScript project aren't code bugs — they're malformed JSON in a config file. .eslintrc.json, tsconfig.json, vercel.json, turbo.json all look like JSON but each has its own quirks, and a single trailing comma can take down your whole pipeline with a cryptic message.

Here are the traps I hit most often, and how to stop wasting time on them.

1. Trailing commas (the #1 culprit)

This is valid JavaScript but invalid JSON:

{
  "extends": "next",
  "rules": {
    "no-unused-vars": "warn",
  }
}

That comma after "warn" throws Unexpected token } in JSON. ESLint, tsc, and Vercel's build all parse these files as strict JSON — no trailing commas allowed.

2. Comments don't belong in plain `.json`

tsconfig.json tolerates comments (it's JSONC). .eslintrc.json and vercel.json do not. Copy a commented snippet from a blog into the wrong file and the parser dies. If you need comments, use the .js/.cjs variant of the config instead.

3. `vercel.json` and `turbo.json` have schemas — use them

Both validate against a JSON Schema. A misspelled key (build vs buildCommand) won't error locally but will silently do nothing on deploy. Validating against the schema catches these before you push. I keep notes on the exact gotchas here: vercel.json guide and turbo.json guide.

4. ESLint flat config + JSON

Migrating to flat config trips people up because the JSON shape changed. The most common failure is still just malformed JSON, not the new structure. I wrote up the specific cases here: validating .eslintrc.json.

A 10-second fix for all of the above

Whenever a config file misbehaves, paste it into a strict JSON validator first — it points to the exact line/column of the problem instead of a vague build error. I built a free in-browser one (no signup, nothing uploaded) for exactly this: jsonic. It formats, validates, and shows a precise error locator, which turns "why is my build broken" into a five-second fix.

TL;DR: Before debugging your build, validate your config JSON. Trailing commas and stray comments cause more failed CI runs than they have any right to.

Why I built yet another JSON formatter (and what I did differently)

Tommy — Thu, 23 Apr 2026 03:35:59 +0000

I've been pasting JSON into random online tools for years. Formatter, type generator, diff —
you name it, there's already 10 versions of it online.

So why build another one?

One day I was debugging a prod API response and copy-pasted the payload into the first
JSON formatter that came up in Google. Then I looked at the network tab.

It had sent my data to a server.

Not a big deal in isolation, but it got me thinking: how many times have I done this
without checking? How many times has someone on my team done it?

What I built

Jsonic — a small toolkit of JSON utilities that run entirely
in the browser. No server. No uploads. Nothing leaves your machine.

Current tools:

Formatter / Minifier / Validator — the basics, done cleanly
JSON → TypeScript — infers proper types including nested objects, arrays, nullable fields
JSON → CSV — handles nested structures by flattening
JSON → YAML
CSV → JSON
JSON Diff — structural diff, not a naive text comparison

The interesting technical bits

The TypeScript inference was harder than expected. The naive approach (just map
JSON types to TS primitives) falls apart quickly:

Arrays with mixed types → (string | number)[]
Fields that are null in the sample but probably typed → string | null
Deeply nested objects → recursive interface generation

The diff was the other tricky one. Text diff on JSON is nearly useless — whitespace
and key order changes produce noise. I implemented a structural diff that compares
the parsed objects, which means reordered keys and re-formatted values don't show
up as changes.

What's next

More tools (TOML, XML, Base64), and eventually some light content so it ranks for
the searches that bring people to these tools in the first place.

If you use JSON tools regularly, I'd love to know what you reach for most.

DEV Community: Tommy