5.110.0
(feat): Add FERN_RUNTIME_ENV_VARS, which defers the listed environment variables past
generation for self-hosted docs. Instead of being substituted with their build-time
value, ${APP_SERVER} is rewritten to a FERN_SELF_HOSTED_ENV_APP_SERVER placeholder
that the self-hosted container resolves on every request, so a single generated image
can serve deployments that differ only in those values.
5.109.3
(fix): Preserve deprecated/x-fern-availability on OpenAPI object properties whose value is a
$ref (or a single-$ref allOf). Previously availability was only read off inline
schemas, so a request body property referencing a deprecated component schema rendered
without a Deprecated badge, while the equivalent query parameter did.
x-fern-availability written alongside a $ref now overrides the referenced schema’s
availability, so a property can opt out of an inherited deprecated.
Note: existing specs may start showing Deprecated (or Beta) badges on properties that reference an already-deprecated component schema, and the corresponding fields in generated SDKs will pick up deprecation annotations. No spec changes are required.
5.109.2
(fix): Warn when generators.yml declares auth-schemes but no api.auth to select them. The
workspace only reads the auth-schemes block when api.auth is set, so declaring schemes
without it silently discards the whole block — env: overrides included — before the importer
sees it. Auth is then re-derived from the spec’s securitySchemes, which carries no
environment variable, and each generator falls back to its own default name (the CLI
generator to <BINARY>_TOKEN). Nothing is invalid, so fern check stayed clean and
generation succeeded while producing a client that read an environment variable the user
never configured. The warning names the schemes being dropped and the auth: line that
applies them.
5.109.1
(fix): Fix fern check and docs previews failing with an uncaught error (e.g. “Expected one of …
Received [object Object]”) when the broken-links rule builds an API definition for an
api section. The rule now resolves the API definition the same way the docs build does,
skips link validation for an API it cannot load, and a rule that throws mid-validation is
reported as a violation honoring its configured severity instead of aborting the command.
5.109.0
(fix): Convert a GraphQL interface to its own set of fields and record each implements clause on the
implementing type, so docs can list an interface’s fields and the types that implement it.
(fix): Don’t document GraphQL operation-namespace types (e.g. a Mutation.checkout: CheckoutMutations
grouping type) as types of their own. Their fields are already documented as operations, so a
type page for them duplicated every field and argument on the referenced types’ pages.
(feat): Record the GraphQL kind (object, input, enum, scalar, interface, union) of every named type
read from a GraphQL schema, so docs can render a Types section.
(feat): GraphQL API references now get a page per named type in the schema, collected under a single
“Types” section and grouped within it by the kind each type was declared with (Objects,
Inputs, Enums, Scalars, Interfaces, Unions). Every GraphQL spec in the API section contributes
to that one section, and it sits at the API root rather than under a subpackage. A kind the
schema does not declare produces no group, and type pages live at <api>/types/<kind>/<type-name>.