@signapps/types

The single source of truth for types and runtime validation. Holds Zod DTOs for every API entity (devices, customers, modules, releases, dashboards…) plus the OpenAPI registry used to generate the API spec.

• Workspace: packages/types  ·  leaf package (no internal deps)
• Build: tsc -p tsconfig.build.json → dist/

How it works

Each domain has a src/dto/<domain>.dto.ts file that defines Zod schemas decorated with .openapi({ title, description }). zodOpenapi.ts re-exports z from Zod extended with the .openapi() method (via @asteasolutions/zod-to-openapi), so schemas can carry OpenAPI metadata.

register.ts collects every domain's registerXSchemas() into one OpenAPIRegistry; the API server feeds that registry into its spec build. The same schemas are reused by @signapps/api-client to validate API responses at runtime.

Exports

package.json exports:

Subpath	Contents
.	All DTO schemas + types, registerAllSchemas, ErrorResponseSchema, the house/ domain
./zodOpenapi	z extended with .openapi()
./dto/*	Individual DTO modules (e.g. ./dto/devices.dto.ts)

Notable details

• Wire format: datetimes use a custom isoDateTime (z.iso.datetime()) so values are ISO-8601 strings — safe for Redux serialization.
• Naming convention: OpenAPI component names map to exported ${Name}Schema symbols; the codegen in api-client relies on this.
• house/ domain: separate entity contracts for Home Assistant entity types (light, sensor, weather, …).