JSON Crack: one monorepo, three builds, and an explicit install allowlist

One repository, three products, and a filter on every script

The root package is called jsoncrack-monorepo and is private, and almost every script is a Turborepo call with a workspace filter. The web app, the VS Code extension and the Chrome extension are separate workspaces, and the scripts name them:

    "dev": "turbo run dev",
    "dev:www": "turbo run dev --filter=www",
    "dev:vscode": "turbo run watch --filter=jsoncrack-vscode",
    "dev:chrome": "turbo run dev --filter=chrome-extension",

Note the asymmetry in the second line. The web and Chrome workspaces expose dev, while the VS Code workspace exposes watch, so pnpm dev:vscode runs a differently named task. Each product also has its own build, its own lint and, for the extensions, its own lint:fix.

What that costs a contributor is attention rather than setup. There is one install, but three artifacts to reason about, and a fix in shared code under packages/ has to be rebuilt and republished three times before a VS Code user, a Chrome user and a web user all have it. The same source, three release trains.

The engine floor is stated in both the README and the manifest: Node.js 24 or newer and pnpm 10 or newer, with the package manager pinned at [email protected] and Turborepo as the only dev dependency at the root.

onlyBuiltDependencies is an allowlist, and a missing entry fails quietly

pnpm does not run dependency install scripts unless they are named, and this manifest names them explicitly:

  "pnpm": {
    "onlyBuiltDependencies": [
      "@vscode/vsce-sign",
      "esbuild",
      "keytar",
      "sharp",
      "unrs-resolver"
    ],

Five packages are allowed to run their build step. Two of them matter immediately: esbuild needs a postinstall to place its binary, and sharp compiles or downloads its native image backend. keytar is a native module for OS keychains, unrs-resolver resolves imports, and @vscode/vsce-sign signs the packaged extension.

The consequence is quiet by design. Add a dependency that needs a build step and pnpm will skip it without failing, so the first symptom is a runtime error such as a missing binary rather than an install error. In a fork, that means an install that appears clean and an application that cannot start.

The fix is a one-line addition to this array, which is also why it is worth knowing: this list, not your package manager, is what decides what compiles on install.

Two transitive versions are forced, and one of them is a sanitizer

The same pnpm block pins two packages that a project would otherwise resolve on its own:

    "overrides": {
      "html-to-image": "1.11.11",
      "monaco-editor>dompurify": "^3.4.13"
    }

The first is an exact pin on html-to-image, which is what turns the graph canvas into a PNG or JPEG. The second targets dompurify only underneath monaco-editor, the code editor embedded in the web app, and floors it at 3.4.13.

Read the second one as a security decision rather than a compatibility one. dompurify sanitises HTML, and the app renders data a user pastes in through an editor that inserts markup, so a floor on the sanitizer is the kind of pin a project keeps until the fix is in the version they depend on. The exact-pin on html-to-image reads the same way, at a patch-level version rather than a floor.

The practical consequence for a fork is that you inherit these pins and the lockfile that encodes them. When an advisory lands upstream, fixing it here is an edit to the root manifest, not a routine dependency bump, and until someone makes that edit your build is pinned to the version the maintainers chose.

The node limit is a build-time constant, not a setting

There is exactly one configuration knob in the README, and its name tells you everything about how it works. The supported node limit can be changed by editing NEXT_PUBLIC_NODE_LIMIT in apps/www/.env.

The NEXT_PUBLIC_ prefix means the value is substituted into the client bundle at build time. It is not read from an environment variable on the server when a request arrives, and it is not a per-user preference. Changing it means editing a file and rebuilding the web app.

So the limit on how large a document your users can open is a property of your deployment, not of their session. A team that expects people to paste multi-megabyte payloads has to set this before building, and a team that wants to raise it temporarily has no way to do it without a redeploy. The README does not give a default value, so you find out what your current limit is by opening a document that is too large and seeing what happens.

The name is also a reminder about the privacy claim. The prefix is what makes a client-side configuration possible in the first place, and it is the same client-side design that lets the project state that all data processing is local and nothing is stored on their servers.

Docker serves the web app on 8888, the dev server on 3000

Self-hosting is a compose file that lives inside one workspace, not at the repository root. The Docker assets are in apps/www, and the commands are:

cd apps/www

# Build a Docker image with:
docker compose build

# Run locally with docker compose
docker compose up

# Go to http://localhost:8888

Port 8888 here, port 3000 for pnpm dev:www. Two different ports, so you can run the container and the dev server at the same time without a collision, which is a small courtesy that saves an afternoon.

What the image contains is worth being precise about: the www app. The VS Code extension and the Chrome extension are separate build outputs from other workspaces, so a Docker deployment gives you the web application and nothing else. If your plan was to self-host the editor and also distribute the extensions from your own infrastructure, this file is only the first of the three things you need.

The development path is the short one. Node 24 and pnpm 10, then a clone, pnpm install, and pnpm dev:www, which reports itself on http://localhost:3000/.

Debugging the VS Code build needs F5 and a namespaced command

The extension workflow is specific enough to copy. Open the repository root in VS Code, press F5, and select Run VSCode Extension (apps/vscode) when prompted. In the Extension Development Host window, open a .json file and run the command JSON Crack: Enable JSON Crack visualization.

Two details carry the information. The launch configuration names its workspace, apps/vscode, so the right one is selected even with three extensions-worth of code in the tree. And the command is namespaced with the product name, which matters in a real user install where several JSON tools may register commands and a bare name would collide.

The distribution surface is equally concrete. There is a VS Code extension in the marketplace under AykutSarac.jsoncrack-vscode, a Chrome extension in the Chrome Web Store, and a published npm package called jsoncrack-react for embedding the viewer in your own React app. Three channels, three releases, one codebase.

The npm package is the one to evaluate first if you are not building a tool. The README's feature list is what lands in it: conversion between JSON, YAML, XML and CSV, formatting and validation, code generation for TypeScript interfaces, Golang structs, Kotlin data classes and Rust serde types, JSON Schema creation and validation, jq and JSON path queries, and image export to PNG, JPEG or SVG.

Version 5.0.0 is from March, the last push is from September

The release history is short enough to read. v1.0 launched on 17 February 2022, v4.0.0 came on 2025-04-29, v5.0.0-beta.1 on 2025-07-20 and v5.0.0 on 2026-03-11. The repository's last push was on 2026-09-14, and it is not archived.

Read those two dates together. There are roughly six months of commits on the default branch that are not in the newest tag, which means the site you use and the release you install are not the same code. That is a normal state for an actively used open source project, and it cuts both ways: you may be getting bug fixes that the tag does not have, and if you pin 5.0.0 you are missing six months of them.

The licence is Apache-2.0 in the manifest, and the setup step in the README adds a note for anyone planning to distribute the code: read the LICENSE file for additional details. That file is LICENSE.md at the root, and it is the authority, not the identifier in package.json.

The last structural fact is who pays for it. The project is by Aykut Saraç, the README links a diagram product at the top, and the Sponsors section points readers to that product with a contact address for sponsorship. Nothing about that changes the Apache-2.0 terms; it is simply the shape of the project, and a commercial dependency in the funding story is a fact worth knowing when you are deciding what to build your tooling on.

Editorial conclusion

Adopt JSON Crack if you want a local-first viewer and formatter for JSON, YAML, XML and CSV, or a VS Code or Chrome extension built from the same code, and if Node 24 and pnpm 10 are available in your environment. Do not adopt it expecting a hosted service that keeps your data server-side, since the project's claim is the opposite: all processing is local. Verify first by cloning and running pnpm dev:www on port 3000, then by checking NEXT_PUBLIC_NODE_LIMIT in apps/www/.env if your documents are large, since that value is compiled in rather than read at runtime.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes