`FormField` with its react-hook-form wiring already done — the control's value/onChange/onBlur/ref, the label association, and the error message.
"sideEffects": ["**/*.css"] so a bundler can drop the package when its exports are unused. Packages that build class names depend on @behivetech/get-class-name (a real dependency, kept external) instead of bundling their own copy of the helper, so an app loads it once.docs.json no longer documents the PartialArgsStillWiden type-test fixture: props docs now cover only the components the package exports from index.ts.
description from the README's first paragraph, and homepage plus a Docs: line in the README pointing at the package's page on https://bht-galaxy.vercel.app, all applied at publish time from one source. Seven READMEs that still said "TODO" have a summary; @behivetech/atoms.stat and @behivetech/cms.base-styles have a README at all; the hand-written props tables are gone from the READMEs, since the Props tab on the site is generated from the interface.pnpm add @behivetech/atoms.button. The versions already on GitHub Packages stay there; nothing in the packages changed.<name>.example.tsx (was <name>.composition.tsx), following template 0.4.0 of the component registry: the published files list and the docs site's Examples tab use the new name. No component code changed.registry/behivetech/<category>/<name> and builds with the template's shared env. Published output is the same code; the class-name helper is bundled into each package instead of being a runtime dependency on @behivetech/get-class-name, the tarball now ships README.md, the source, the compositions and a docs.json the docs site reads, and each package declares license: MIT.f8c57db: Generate TypeScript declarations once per build instead of once per format.
dist/index.d.cts is no longer emitted. Nothing referenced it: each package's exports["."].types points at dist/index.d.ts, which is unchanged and still covers both the import and require conditions. There are no API, type, or runtime changes.
Updated dependencies [f8c57db]
b98ff2a: narrow the render prop's value to the named field
ManagedField and FormFieldManagedProps now take TName as a second type
parameter and thread it into ControllerRenderProps. Previously TName sat at
its default, so field.value widened to a union of every field type in the
form and each call site needed value={field.value as string} — an assertion
that keeps compiling if the field later changes type, which is the mistake the
generic exists to prevent. rules.validate had the same problem.
The parameter defaults to the old behaviour, so existing callers, casts and all, keep compiling.
Getting the narrowing depends on how the generics are supplied. Passing
control infers both parameters and needs no annotation. Reading control from
context means naming both — <FormFieldManaged<Values, "email">. Supplying only
the first, <FormFieldManaged<Values>, does not narrow: TypeScript stops
inferring the remaining parameters once any is given explicitly. The README and
the component docstring cover both working forms, and a type test now enforces
the narrowing under check-types, which spec files are excluded from.