Better TypeScript support in Featurevisor

Featurevisor now offers better TypeScript support for evaluating variations and variables in JavaScript, React, and Vue applications. Existing code continues to work as before, while applications can opt into stricter result types where they are useful.
Optional types in the JavaScript SDK#
Featurevisor has always returned predictable broad types from its evaluation methods:
const variation = f.getVariation('checkout')// string | nullconst config = f.getVariable('checkout', 'config')// VariableValue | nullThose calls do not need to change.
TypeScript applications can now provide their expected result types when they want narrower values:
type CheckoutVariation = 'control' | 'treatment'const variation = f.getVariation<CheckoutVariation>('checkout')// CheckoutVariation | nullVariables can use application interfaces as well:
interface CheckoutConfig { title: string maxItems: number showDiscount: boolean}const config = f.getVariable<CheckoutConfig>('checkout', 'config')// CheckoutConfig | nullThe same optional types are available from child instances, so applications can preserve their expected types while evaluating with child context and sticky state.
React applications#
The React hooks follow the same API:
import { useVariable, useVariation } from '@featurevisor/react'type CheckoutVariation = 'control' | 'treatment'interface CheckoutConfig { title: string maxItems: number}function Checkout() { const variation = useVariation<CheckoutVariation>('checkout') const config = useVariable<CheckoutConfig>('checkout', 'config') return ( <section> <h1>{config?.title ?? 'Checkout'}</h1> <p>Variation: {variation ?? 'unavailable'}</p> </section> )}Calls without a type argument continue returning the established broad types. Applications can introduce stricter typing gradually without rewriting every existing hook call.
The methods returned by useFeaturevisor() also preserve the same generic signatures, which is useful when a component prefers Featurevisor's imperative React API.
Vue applications#
Vue composables now provide the same experience:
<script setup lang="ts">import { useVariable, useVariation } from '@featurevisor/vue'type CheckoutVariation = 'control' | 'treatment'interface CheckoutConfig { title: string maxItems: number}const variation = useVariation<CheckoutVariation>('checkout')const config = useVariable<CheckoutConfig>('checkout', 'config')</script><template> <section> <h1>{{ config?.title ?? 'Checkout' }}</h1> <p>Variation: {{ variation ?? 'unavailable' }}</p> </section></template>React and Vue now stay aligned with the main JavaScript SDK, so teams can use the same types when evaluation code moves between application layers.
Runtime behaviour stays the same#
Generic result types describe what the application expects at compile time. They do not validate, parse, or transform the value at runtime.
Featurevisor still offers type specific variable methods when runtime checking is required:
const enabled = f.getVariableBoolean('checkout', 'showDiscount')const title = f.getVariableString('checkout', 'title')const maxItems = f.getVariableInteger('checkout', 'maxItems')const steps = f.getVariableArray<number>('checkout', 'steps')const config = f.getVariableObject<CheckoutConfig>('checkout', 'config')These methods return null when the evaluated value does not have the requested top level runtime type. Array item types and object shapes supplied as generics remain compile time expectations. Optional generics on getVariation() and getVariable() work the same way.
Project aware types with code generation#
Explicit types are useful when application code already owns the relevant interface or union. For stronger project wide support, Featurevisor can generate types directly from feature definitions:
$ npx featurevisor generate-code \ --language=typescript \ --out-dir=./src/featurevisorGenerated helpers know the available feature keys, variable keys, variation values, and variable schemas for the selected project. Their result types flow through the same generic APIs used by the JavaScript and React packages.
This gives teams two complementary options:
- Add an optional type directly when a local application type already exists.
- Use code generation when types should come from the Featurevisor project itself.
Existing applications remain compatible#
The new type parameters are optional and disappear from the emitted JavaScript. Evaluation logic, datafiles, bucketing, runtime validation, and browser performance remain unchanged.
One narrow TypeScript consideration applies to custom wrappers and test doubles. Code that implements Featurevisor['getVariation'] or Featurevisor['getVariable'] must now preserve the corresponding generic call signature. Ordinary SDK and framework calls are unaffected. The JavaScript SDK guide includes a complete test double example.
Get started#
Read the updated guides for the API that your application uses:
The result is a familiar Featurevisor API with stronger TypeScript support whenever an application chooses to use it.

