How to type-safely pass unknown (Zod-parsed config) to a JsonB field without casting to InputJsonValue?

[TomasTokaMrazek]

Question

I have a generic component lifecycle system where configuration is parsed by Zod schemas at the service layer and then written to a JsonB column via a repository. To keep the repository and service layers decoupled from specific config shapes, the repository method accepts unknown:

public updateComponent(type: string, configuration?: unknown): Effect<Component, RepositoryError> {
    return tryPrisma(() => this.prisma.component.update({
        where: { type },
        data: {
            configuration: configuration ?? Prisma.skip,
        },
    }));
}

This produces a type error because unknown is not assignable to InputJsonValue | typeof Prisma.skip.

I currently bridge the gap with a helper at the repository boundary:

private toJsonValue(value: unknown): Prisma.InputJsonValue | typeof Prisma.skip {
    if (value === undefined) return Prisma.skip;
    return value as Prisma.InputJsonValue; // <-- cast I'd like to remove
}

The values always come from schema.safeParse() using Zod strict-object schemas, so they're always valid JSON (no symbols, bigints, functions, or non-serializable values). But TypeScript can't prove it.

What I've considered and why each doesn't satisfy me:

• Type predicate (v is Prisma.InputJsonValue) — same escape hatch as as, just spelled differently. TypeScript trusts the predicate body without verifying it.
• Accept Prisma.InputJsonValue at the service level — couples domain types to Prisma's generated types, which I'm trying to avoid.
• JSON.parse(JSON.stringify(value)) — I used this, but it adds runtime overhead and still produces unknown.

Questions:

• Is there a supported pattern in the Prisma ecosystem for this? For example, does Prisma.JsonValue or runtime.InputJsonValue export something that makes this narrowing cleaner?
• Is there a Zod integration (zod-prisma or otherwise) that produces types directly assignable to InputJsonValue?
• Or is the single bounded as InputJsonValue at the storage boundary the intended pattern here — i.e., by design InputJsonValue is not meant to be narrowed to from unknown without a cast?

How to reproduce (optional)

No response

Expected behavior (optional)

No response

Information about Prisma Schema, Client Queries and Environment (optional)

• Database: PostgreSQL

• Node.js version: v24.15.0

• Run prisma -v to see your Prisma version and paste it

prisma               : 7.7.0
@prisma/client       : 7.7.0
Operating System     : linux
Architecture         : x64
Node.js              : v24.15.0
TypeScript           : 6.0.3
Query Compiler       : enabled
PSL                  : @prisma/prisma-schema-wasm 7.6.0-1.75cbdc1eb7150937890ad5465d861175c6624711
Schema Engine        : schema-engine-cli 75cbdc1eb7150937890ad5465d861175c6624711 (at node_modules/@prisma/engines/schema-engine-debian-openssl-3.0.x)
Default Engines Hash : 75cbdc1eb7150937890ad5465d861175c6624711
Studio               : 0.27.3
Preview Features     : strictUndefinedChecks

[x-tahosin]

This is a genuinely hard TypeScript problem. You're caught between three design constraints:

1. Zod's parse() output is unknown (correct — it could theoretically be anything)
2. Prisma's InputJsonValue is a closed union that only accepts string | number | boolean | null | JsonObject | JsonArray
3. You want to avoid as casts because they defeat the type-safety you're paying for

The core issue is that TypeScript's type system cannot "see through" a Zod parse into the literal structure of your schema. Even with strictObject, the inferred type is still too wide for Prisma's discriminated union.

The pragmatic solution: a typed wrapper

Instead of fighting the type system, add a thin runtime+type boundary at the point where your domain model meets Prisma. Here's the pattern I use in production:

import { Prisma } from '@prisma/client';

/**
 * Domain-to-Prisma JSON bridge.
 * This accepts anything Zod produces and returns Prisma's JSON type,
 * with a small runtime check for serializability.
 */
function toJsonValue<T>(
  value: T
): Prisma.InputJsonValue | typeof Prisma.skip {
  if (value === undefined || value === null) {
    return Prisma.skip;
  }

  // Runtime guard: ensure value is JSON-serializable
  // This catches symbols, functions, undefined in objects, etc.
  try {
    JSON.stringify(value);
  } catch {
    throw new Error('Value is not JSON-serializable');
  }

  // Return the same value but typed as InputJsonValue.
  // The `JSON.stringify` check acts as our runtime proof.
  return value as unknown as Prisma.InputJsonValue;
}

Then your repository method becomes:

public updateComponent(
  type: string,
  configuration?: unknown
): Effect<Component, RepositoryError> {
  return tryPrisma(() =>
    this.prisma.component.update({
      where: { type },
      data: {
        configuration: toJsonValue(configuration),
      },
    })
  );
}

Why this is better than the alternatives you considered

Approach	Problem	Wrapper solution
Type predicate	TypeScript trusts your predicate body; no actual narrowing happens	Runtime JSON.stringify check provides real validation
Accept InputJsonValue at service layer	Couples domain types to Prisma	unknown stays at boundary; only toJsonValue knows Prisma
JSON.parse(JSON.stringify(value))	Adds runtime overhead + still produces unknown	No parse overhead; just a stringify check and type cast

Alternative: branded type + Zod refinement

If you want to eliminate the as cast entirely, create a branded type that Zod produces and Prisma accepts:

// Branded type: "this unknown has been proven JSON-safe"
type JsonSafe<T = unknown> = T & { readonly __jsonSafe: true };

function jsonSafe<T>(value: T): JsonSafe<T> {
  JSON.stringify(value); // throws if invalid
  return value as JsonSafe<T>;
}

// Zod schema that produces JsonSafe
defineConfigSchema = z.strictObject({
  // ... your fields
}).transform((data) => jsonSafe(data));

// Then in Prisma, extend the generated types
// (requires a small type declaration merge)
declare global {
  namespace Prisma {
    type InputJsonValue = JsonSafe | string | number | boolean | null | JsonObject | JsonArray;
  }
}

This is more work but gives you zero casts in application code. However, I only recommend this for large teams where the branded-type discipline is worth the overhead.

The honest answer about Prisma's types

Prisma's InputJsonValue is intentionally conservative. It doesn't accept unknown because its runtime serializer needs to guarantee it can produce valid JSON for PostgreSQL's jsonb column. The JSON.stringify runtime check is the only way to bridge the gap without either:

• Relaxing Prisma's type safety (bad for the ecosystem)
• Adding a Zod-specific dependency inside Prisma (not their responsibility)

Bottom line

Use the toJsonValue wrapper above. It's one function, no dependencies beyond what you already have, and it keeps your service layer decoupled from Prisma while providing real runtime safety. The as cast inside toJsonValue is contained, documented, and justified by the JSON.stringify proof.

If you want, I can also show how to make toJsonValue generic over your Zod schemas so the return type narrows from unknown to your specific inferred shape, giving you full end-to-end type safety from Zod → service → Prisma.

[nurul3101]

Hello 👋

The bounded cast at the storage boundary is the intended pattern, and there's no built-in narrower from unknown to InputJsonValue.

On Prisma exports, the runtime package gives you JsonValue, InputJsonValue, JsonObject, InputJsonObject, JsonArray, and InputJsonArray as types only. There's no isInputJsonValue runtime helper or branded validator. The Input variants exclude null because writes need Prisma.JsonNull or Prisma.DbNull explicitly, which is why you can't round-trip a JsonValue read straight back as an InputJsonValue write.

On Zod integrations, nothing produces types that drop in for InputJsonValue. prisma-json-types-generator works on the output side, making JsonValue more specific, and zod-prisma-types generates schemas for Prisma's model input types like ComponentUpdateInput, not free-form JSON. You can hand-write a recursive Zod schema typed against InputJsonValue and intersect it with your strict-object schemas, but that pulls the Prisma type back into your schema definitions, which is the coupling you're trying to avoid.

One alternative worth trying before settling on the cast: make the repository method generic with a JSON constraint, which moves the structural check to the call site instead of the implementation.

public updateComponent<T extends Prisma.InputJsonValue>(
  type: string,
  configuration?: T,
): Effect<Component, RepositoryError> {
  return tryPrisma(() => this.prisma.component.update({
    where: { type },
    data: { configuration: configuration ?? Prisma.skip },
  }));
}

[github-actions[bot]]

Hi,

As we have not heard back from you, we are closing this discussion to keep our discussions organized.

Feel free to start a new discussion if this remains relevant.

Thank you for being part of the community!

[phlppgdfry]

You've correctly identified the fundamental tension here: TypeScript can't prove that a Zod-validated value satisfies Prisma.InputJsonValue structurally, because InputJsonValue is a recursive union that TypeScript can't narrow into from unknown without a cast.

The intended pattern

The single bounded as Prisma.InputJsonValue cast at the repository/storage boundary is the intended pattern. Prisma's own documentation acknowledges this and considers it acceptable because:

1. InputJsonValue is defined as string | number | boolean | null | InputJsonValue[] | { [key: string]: InputJsonValue } — exactly what a strict Zod schema produces
2. The cast is constrained (you're casting to a specific type, not any)
3. It's isolated to a single point at the storage boundary

Cleaner helper approach (still has a cast, but narrows it)

The cleanest version without coupling your domain to Prisma types:

// In your repository infrastructure layer only
import { Prisma } from '@prisma/client'

/**
 * Converts a Zod-parsed value to Prisma's InputJsonValue.
 * Safe to use because Zod strict schemas produce only JSON-serializable output.
 * The cast here is a known-safe boundary between domain and persistence layers.
 */
export function toInputJson(value: unknown): Prisma.InputJsonValue {
  return value as Prisma.InputJsonValue
}

export function toInputJsonOrSkip(
  value: unknown
): Prisma.InputJsonValue | typeof Prisma.skip {
  if (value === undefined) return Prisma.skip
  return value as Prisma.InputJsonValue
}

This gives you a single named cast point that documents its intent. Your repo becomes:

public updateComponent(type: string, configuration?: unknown) {
  return tryPrisma(() => this.prisma.component.update({
    where: { type },
    data: {
      configuration: toInputJsonOrSkip(configuration),
    },
  }))
}

Zod integration option

If you want to avoid the cast entirely at the cost of some coupling, zod-prisma-types generates Zod schemas from your Prisma schema. For JsonB fields it generates schemas that produce Prisma.InputJsonValue directly:

import { ComponentOptionalDefaultsSchema } from './generated/zod'
// ComponentOptionalDefaultsSchema.shape.configuration produces Prisma.InputJsonValue

But this couples your service layer schemas to generated Prisma types — the opposite of what you want.

JSON.parse(JSON.stringify()) alternative

You already found this doesn't help (still returns unknown). It also silently drops undefined values in objects, which can cause subtle bugs.

Answer to your specific questions

• Supported pattern? Yes — as Prisma.InputJsonValue at the storage boundary is explicitly the intended approach. See Prisma docs on working with JSON fields.
• Zod integration? zod-prisma-types can generate compatible schemas, but at the cost of coupling.
• Is the cast by design? Yes. TypeScript cannot prove recursive JSON-serializability; the cast is the escape hatch Prisma expects you to use at the persistence boundary.

[Krishna11118]

The single bounded cast at the storage boundary is the intended pattern here — but you can make it safer and more explicit.

Recommended approach: narrow with a type guard at the boundary

Instead of a bare as cast, use a type predicate that documents the invariant:

function isInputJsonValue(value: unknown): value is Prisma.InputJsonValue {
  // Prisma.InputJsonValue accepts any JSON-serializable value.
  // Values from Zod strict-object schemas are always valid JSON,
  // so this guard is a documented assertion, not a runtime check.
  return value !== undefined;
}

public updateComponent(type: string, configuration?: unknown) {
  return tryPrisma(() => this.prisma.component.update({
    where: { type },
    data: {
      configuration: isInputJsonValue(configuration)
        ? configuration
        : Prisma.skip,
    },
  }));
}

This is semantically equivalent to your cast, but it reads as a deliberate boundary assertion rather than a suppressed type error.

Using zod-to-prisma types (zod-prisma-types)

If you use zod-prisma-types to generate your Zod schemas from the Prisma schema, the generated schemas produce types that are directly assignable to InputJsonValue. This removes the cast entirely by aligning the type at schema generation time.

Is JSON.parse(JSON.stringify(value)) worth it?

No — for Zod-validated strict-object outputs, the serialization round-trip adds overhead with no type benefit since you still get unknown back. The type predicate approach above is cleaner.

Why Prisma does not expose a narrowing-friendly type

InputJsonValue is intentionally broad because Prisma cannot statically know the shape of your JSON columns. The design expectation is that you own the boundary — your repository layer is exactly the right place to make this assertion.