About any in source code

[ShionTerunaga]

Note

It's just a question I have.

Target source code

packages/zod/src/v4/core/registries.ts

  add<S extends Schema>(
    schema: S,
    ..._meta: undefined extends Meta ? [$replace<Meta, S>?] : [$replace<Meta, S>]
  ): this {
    const meta: any = _meta[0];
    this._map.set(schema, meta!);
    if (meta && typeof meta === "object" && "id" in meta) {
      if (this._idmap.has(meta.id!)) {
        throw new Error(`ID ${meta.id} already exists in the registry`);
      }
      this._idmap.set(meta.id!, schema);
    }
    return this as any;
  }

Background

I try not to use any as much as possible in my daily work because it compromises security.

While reading this source code to improve my skills, I noticed that any was defined in the above source code and thought that it might be possible to perform type guarding at runtime.

One proposal

add<S extends Schema>(
  schema: S,
  ..._meta: undefined extends Meta
    ? [$replace<Meta, S>?]
    : [$replace<Meta, S>]
): this {
  const meta = _meta[0];

  this._map.set(schema, meta!);

  if (meta && typeof meta === "object" && "id" in meta && typeof meta.id === "string") {
    if (this._idmap.has(meta.id)) {
      throw new Error(`ID ${meta.id} はすでに登録されています。`);
    }

    this._idmap.set(meta.id, schema);
  }

  return this;
}

For example, I thought that it could be converted to the above source code.
Removing any adds one more condition, but I personally thought that this would be fine.

Is it okay to change the above source code?

[dosubot[bot]]

Hi @ShionTerunaga! I'm Dosu and I’m helping the zod team.

I'm a bot trained on Zod's codebase and issues.

The use of any in the add method is intentional to handle highly dynamic and complex metadata types, especially since $replace<Meta, S> can produce arbitrarily shaped objects depending on the schema and metadata involved. This casting allows Zod to support flexible registry patterns and advanced meta-programming, while still enforcing type safety at the API level through TypeScript generics elsewhere in the codebase. Runtime type guards like typeof meta.id === "string" are safe to add and can improve runtime safety, but removing any entirely may not be feasible without breaking compatibility with the current flexible design of registries and metadata handling. The current approach is a compromise to balance type inference, flexibility, and runtime safety in advanced scenarios like recursive schemas and custom registries cite.

If your use case allows for stricter runtime checks, your proposed change is reasonable for your own code, but be aware it could restrict some advanced usage patterns that Zod supports by design. For best practices, avoid any where possible, but in cases like this—where TypeScript's type system can't fully express the runtime flexibility needed—it's an accepted tradeoff in the Zod codebase.

If this answers your question, please close the issue!

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[ShionTerunaga]

@dosu

Thank you for your reply.

If your use case allows for stricter runtime checks, your proposed change is reasonable for your own code, but be aware it could restrict some advanced usage patterns that Zod supports by design.

Specifically, what areas could be affected?
Please explain in detail.

[dosubot[bot]]

Great question! The use of any in the registry's add method is what enables Zod to support highly dynamic and advanced metadata patterns. If you replace any with stricter runtime checks (like always requiring meta.id to be a string), you risk breaking or restricting several advanced features:

• Recursive and complex metadata: Zod registries can store metadata that is deeply nested, includes functions, or references the inferred output type of a schema (for example, an examples field containing values of z.$output[]). This is possible because the $replace<Meta, S> type can produce arbitrarily complex shapes, and any allows the registry to accept and store them without runtime type errors. Strict runtime checks would block these patterns and make it impossible to use metadata that isn't a simple object with a string id see docs.

• Custom registries and extensibility: Users can define custom registries with their own metadata types, including types that reference schema outputs, arrays, or even functions. The flexibility of any is what allows these custom patterns to work seamlessly see docs.

• JSON Schema generation and interlinked schemas: Zod's JSON Schema generator relies on the registry's ability to store arbitrary metadata and link schemas via the id property. The metadata is merged into the JSON Schema output without strict type assumptions, so enforcing stricter checks would break this workflow and prevent advanced schema linking see docs.

• Metadata inheritance and merging: The registry supports inheriting and merging metadata from parent schemas, which involves dynamic object merging. This is only possible because the metadata type is flexible and not strictly enforced at runtime see code.

In short, enforcing stricter runtime checks would reduce extensibility and break compatibility with advanced Zod features that rely on dynamic, arbitrarily-shaped metadata. The current use of any is a deliberate design choice to support these patterns see discussion.

If this clarifies things, feel free to close the issue!

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.