All tools

package.json "exports" Field Validator

Code

Parse a package.json's exports map and flag common dual-package (ESM/CJS) misconfigurations: a types condition not listed first, a missing default fallback, mismatched require/import extensions, mixed subpath and condition keys, and a subpath pattern with no matching *

Paste a package.json and get its exports field checked against the structural rules Node's module resolver actually enforces, not just whether the JSON parses. It flags a types condition that isn't listed first (TypeScript won't pick it up reliably otherwise), a missing default fallback, a require condition pointing at a .mjs file or an import condition pointing at a .cjs file, subpath and condition keys mixed in the same object, and a pattern key like ./features/* whose target has no * to receive the matched text. This fills a real gap for anyone shipping a dual ESM/CJS package, where these mistakes compile fine but break at resolution time in a consumer's project.

package-jsonexportsesmcommonjsnodedual-package

How to use package.json "exports" Field Validator

  • 1.Paste your full package.json (only the exports field is read).
  • 2.Review the flagged issues, each one points at the exact path inside exports where something is missing or malformed.
  • 3.Fix the errors (they break resolution) and consider the warnings (ordering and fallback conventions that TypeScript and Node both rely on).

Frequently asked questions

Does this replace running my package with Node to test resolution?
No, it's a static structural check based on the documented exports rules. It doesn't actually resolve imports against your filesystem, so a path that's structurally valid but points at a file that doesn't exist won't be caught.
Why does it warn about "types" not being listed first?
TypeScript's resolver picks the first matching condition it recognizes when resolving type declarations for a dual-package export, so if "types" isn't first, an editor or tsc can end up resolving a .js file's shape instead of your .d.ts, or fail to find types at all depending on the resolver mode.
What counts as "mixing subpath and condition keys"?
An exports object where some keys start with "." (subpaths like "." or "./feature") and others don't (conditions like "import" or "require") in the same object. Node's resolver treats this as invalid since it can't tell whether the object represents subpaths or conditions.
Does it check that the referenced files actually exist?
No. It only validates the shape of the exports value itself: extensions, key ordering, pattern matching, and structural rules, not whether the target paths resolve to real files on disk.

Use via API, SDK, or MCP

cURL# Free: 1,000 req/day · Pro: 10,000 req/day
curl -X POST https://api.utilix.tech/v1/tools/package-json-exports-validator \
  -H "Authorization: Bearer utx_live_..." \
  -H "Content-Type: application/json" \
  -d '{"text":"{\n  \"name\": \"pkg\",\n  \"exports\": {\n    \"types\": \"./dist/index.d.ts\",\n    \"import\": \"./dist/index.mjs\",\n    \"require\": \"./dist/index.cjs\",\n    \"default\": \"./dist/index.cjs\"\n  }\n}\n"}'

Get an API key from your dashboard · Full API docs →