AREA GUIDE / 2 PACKAGES

Schemas, types and results

Make input, output, serialization and failure behavior explicit across the boundaries your product exposes.

What are you trying to do?

  • How do Zod, JSON Schema and GraphQL representations relate?
  • Where do standard results and errors live?
  • Which types are runtime validation and which are compile-time helpers?
FIND YOUR WAY THROUGH THIS AREA

Start with the work you want to do.

Choose a practical step, then inspect a package before opening its full manual.

STEP 01

Inspect both directions

Follow one input from its schema to transport parsing, then follow one output back through serialization. Include an absent field, an invalid value and an enum value that needs wire-name conversion in your review of the existing tests.

THE PACKAGE LANDSCAPE

2 packages. Choose an entry point.

2 packagesSELECT TO INSPECT

Task guidance and package membership come from this area’s captured source guide.

Start with these packages.

lib.schema

Use schema models and the existing Zod, JSON Schema, GraphQL and entity surfaces.

Read the package guide →
lib.contracts-spec-core

Use canonical result and query primitives shared by contracts and adapters.

Read the package guide →
lib.utils-typescript

Use existing utility types for compile-time transformations without confusing them with runtime validation.

Read the package guide →

Choose a representation intentionally

The schema package provides SchemaModel, field/scalar/enum helpers, entity definitions and explicit projection surfaces for Zod, JSON Schema and GraphQL. Pick the model that the consuming contract already uses, then inspect how its selected transport obtains a wire schema. TypeScript utility types serve a different purpose: they help code describe transformed values at compile time. They do not establish that an incoming request satisfies the same rules. Keep the runtime validation boundary visible in the operation or adapter you are integrating.

Understand projection differences

A schema projection may change the representation while preserving domain meaning. EnumType is a concrete example: domain strings remain unchanged in Zod and JSON Schema, while GraphQL requires valid enum identifiers. The documented projection replaces invalid characters, prefixes unsuitable leading forms and rejects resulting name collisions. Parsing and serialization map the wire name back to the domain value. Review such rules before sharing enums between REST, GraphQL, stored records and UI selections; matching labels alone are insufficient.

Use one result vocabulary

Portable Core exposes results, standard outcomes, normalization and compatibility helpers alongside query envelopes. Read these definitions before wrapping a successful value or error in a new application-specific shape. A field-validation failure, policy denial, unavailable provider and handler failure are different situations for a caller. Preserve their declared meaning through the adapter and the user interface. Keep sensitive implementation details out of a public error while retaining a safe correlation path for diagnostics.

Follow a practical path.

  1. Inspect both directions

    Follow one input from its schema to transport parsing, then follow one output back through serialization. Include an absent field, an invalid value and an enum value that needs wire-name conversion in your review of the existing tests.

  2. Compare the actual exported leaf

    Open the package export map and the selected schema implementation. Check whether the consumer needs the root, entity, or individual projection entry. Use the same canonical model rather than creating parallel definitions for each transport.

  3. Exercise a meaningful mismatch

    Use the owning project’s schema tests to examine how rejected input becomes a declared result. Add a case only when it resolves a real integration risk, such as a projection collision or an error shape that a client cannot interpret.

All packages in this area.

2 packages
foundation / library

lib.schema

v6.0.5
Package manifestGuide availablenode

Schema utilities for Zod, JSON Schema, and GraphQL

@lssm-tech/lib.schema
14Declared imports
5Direct dependencies
Inspect this packageImports · dependencies · qualification

Declared import paths

manifest-declared export entrypoints and catalog-declared imports

Showing 6 of 14 declared entry points.

Dependency declarations
Runtime
2
Peer
0
Development
3
Optional
0
  • graphqlcatalog:graphql · runtime
  • zodcatalog: · runtime
  • @lssm-tech/tool.typescriptworkspace:* · development
  • typescriptcatalog: · development
  • @lssm-tech/tool.bunworkspace:* · development

Showing 5 of 5 declarations across scopes. A package may appear in more than one scope.

Package and source context
Package scope
No private flag declared in the manifest
Source guide
README available
Declared runtimes
node
Declared stability
stable
Source path
packages/foundation/schema

Manifest declarations describe this source snapshot; they do not verify registry publication or runtime execution.

foundation / library

lib.utils-typescript

v5.0.4
Package manifestGuide availablenode

TypeScript utility types and helpers

@lssm-tech/lib.utils-typescript
34Declared imports
4Direct dependencies
Inspect this packageImports · dependencies · qualification

Declared import paths

manifest-declared export entrypoints and catalog-declared imports

Showing 6 of 34 declared entry points.

Dependency declarations
Runtime
1
Peer
0
Development
3
Optional
0
  • @lssm-tech/lib.contracts-spec-coreworkspace:^ · runtime
  • @lssm-tech/tool.typescriptworkspace:* · development
  • typescriptcatalog: · development
  • @lssm-tech/tool.bunworkspace:* · development

Showing 4 of 4 declarations across scopes. A package may appear in more than one scope.

Package and source context
Package scope
No private flag declared in the manifest
Source guide
README available
Declared runtimes
node
Declared stability
stable
Source path
packages/foundation/utils-typescript

Manifest declarations describe this source snapshot; they do not verify registry publication or runtime execution.

Your view

Make room for your context.

Shape the presentation around this moment. You can change it whenever you need.

Your context

The different parts of you

Choose a starting point

A useful mix of context, visuals and gentle guidance.

Tune each dimension
Each dimension can change independently. Product permissions and available actions stay unchanged.

Support the way you begin and return

Tune your support

Reading comfort

Choose your language

Interface language changes text only. Markets, prices and workflows keep their own settings.

Translation coverage

Original source

Navigation151
Graph616
Categories378
Portfolio833
Examples2,035
Source preview1,542

More translations will be added as content is reviewed.

This preference is saved on this browser.

Search the website

Useful starting points

No results. Try a shorter phrase, an operation name or another search area.

A LITTLE ROOM TO EXPLORE

Find something to explore.

Open a closer look on this page, try a different perspective, or follow the detail into its own page.

How previews and controls work
01

Look before you leave

Hover a link or focus it with Tab to see a preview. Clicking the original link or pressing Enter always opens its destination.

02

Stay with the context

Move into the preview to explore its sections. Use Alt + ↓ from a focused link to enter it with the keyboard. Escape closes it.

03

Open the possibilities

Disclosure rows, perspective choices and highlighted controls reveal more. Your view changes reading comfort and the context you explore.

A separate button for a closer look

Show small preview buttons beside links where there is room. Tap the eye to inspect, or tap the link to go straight there. This choice stays in this tab.

No browsing history is collected. Reduced motion follows your device and Your view.