v0.1.9

Added

• Strict MDX types from the Remix adapter. @withsprinkles/content-layer/remix now exports:
  • MDXComponents — a map of intrinsic tag names (or arbitrary keys) to remix/ui factories or string tag names, with optional wrapper. Mirrors @types/mdx's MDXComponents but with remix/ui's factory shape.
  • MDXProps — extensible bag of props with an optional components field.
  • MDXContent — the factory shape exposed as the generated Content component.

Changed

• The Remix adapter's componentType now points at import(\"@withsprinkles/content-layer/remix\").MDXContent, so consumer-generated Content types get per-element prop typing on overrides instead of Record<string, unknown>.
• remix is now an optional peer dependency (only required by the Remix adapter).

v0.1.8

Fixed

• Remix adapter Content is now typed as a Handle-taking factory. The 0.1.7 componentType ((props?) => () => RemixNode) didn't match remix/ui's JSX factory contract, so consumers using <Content /> got 'Content' cannot be used as a JSX component. The new type, (handle: Handle<{ components?: Record<string, unknown> }>) => () => RemixNode, matches what the wrap is doing at runtime.

v0.1.7

Fixed

• Content from the Remix adapter now forwards props to MDX. Previously the wrap discarded all props (Content = () => () => MdxComponent({})), so <Content components={...} /> never reached the MDX-compiled component. The wrap now forwards handle.props, enabling consumers to pass components (and any other MDX prop) through.

Changed

• The Remix adapter's componentType is now (props?: { components?: Record<string, unknown>; [key: string]: unknown }) => () => RemixNode, reflecting the props-forwarding fix.

v0.1.6

Fixed

• Validation errors now show which field failed. Previously, parseData flattened every Standard Schema issue's message into a single comma-separated string, hiding the path of the failing field — e.g. Validation failed for entry "post": Expected string, Expected object. Errors are now formatted with one issue per line, prefixed by the offending path: image.src: Expected string.

v0.1.5

Target remix/ui for componentType in the Remix adapter (Remix 3.0.0-beta.2 moved RemixNode from remix/component to remix/ui).

v0.1.4

Fixes

• findImporter now resolves entries by their collection, not by scanning stores by ID. Previously findCollectionForEntry walked every store and returned the first one whose keys contained entry.id, so two collections sharing an entry ID would silently route render(entry) to the wrong MDX importer (or throw No content found for entry "..." if the wrongly-picked collection had no matching slot). The collection is already attached to every entry during store serialization, so findImporter now reads entry.collection directly. Fixes cl-b2h.

Additions

• New type exports: InferSchemaOutput<S> and ResolveSchema<T>. These were previously inlined inside the generated sprinkles:content module; lifting them into the package's public types deduplicates the codegen template and lets consumers (and our own type tests) reference the helpers directly.
• Type-level tests for schema propagation through getCollection / getEntry / getEntries / render / reference, wired via Vitest's typecheck mode. These guard against the class of regressions fixed in v0.1.2 and v0.1.3.

Compatibility

No breaking changes. Consumers whose collection IDs already don't collide see no runtime behavior change. The emitted sprinkles:content type declaration now imports InferSchemaOutput and ResolveSchema from @withsprinkles/content-layer — this regenerates automatically on the next vp dev / vp build, no manual action needed.

v0.1.3

Fixes

• Collection data types are no longer widened to any in downstream code. The generated sprinkles:content module referenced @standard-schema/spec directly, but that package is only a transitive dependency — consumers don't list it, so the import silently resolved to any and cascaded into DataEntry<any>. The generated module now references StandardSchemaV1 through @withsprinkles/content-layer (which every consumer already has) and inlines its own _InferSchemaOutput helper to read a schema's ~standard.types.output without a third-party import.
• reference() now preserves the collection string literal. Previously reference("authors") returned a schema producing { collection: string; id: string }, which meant getEntry(post.data.author) widened to the union of all collections instead of resolving to the target collection's entry type. reference<C extends string>(collection: C) now returns ReferenceSchema<C>, so post.data.author.collection is "authors" and getEntry(post.data.author) returns CollectionEntry<"authors">.

Exports

• StandardSchemaV1 is now re-exported as a type from the package root so generated types and advanced consumers can reference it without importing @standard-schema/spec directly.

Compatibility

No breaking runtime changes. Consumers who were relying on the old any-widened types may see new type errors surface — these were always real bugs being masked.

v0.1.2

Fixes

• reference() now type-checks when used inside @remix-run/data-schema's s.object({ ... }), s.array(...), and other nested combinators. The return type has been tightened from StandardSchemaV1<string, Reference> (async-allowed) to a sync-only variant, and structural stubs for pipe/refine have been added so the helper is assignable to data-schema's Schema<any, any> shape without taking a runtime dependency on data-schema.

Notes

• The pipe and refine methods are no-ops at runtime — they're present only for type compatibility. Since reference IDs are strings, additional checks belong on the outer combinator that consumes the resolved entry, not on the reference helper.
• Runtime behavior of reference() is unchanged from 0.1.1. Consumers using Zod, Valibot, ArkType, or other Standard Schema libraries remain unaffected.

v0.1.1

Fixes

• reference() now composes inside @remix-run/data-schema's nested combinators (s.object, s.array, s.lazy, etc.). Previously it only exposed Standard Schema v1's ~standard.validate, but data-schema's combinators walk children via a ~run method (a Valibot/data-schema convention that sits alongside Standard Schema). The helper now exposes both interfaces, so schema: s.object({ author: reference("authors") }) works as expected. Nested validation errors carry the correct path.

Compatibility

This release is backward compatible. Consumers using Zod, Valibot, ArkType, or any other Standard Schema library remain unaffected.

v0.1.0

Initial release