Registry / testing / ts-expect

ts-expect

JSON →
library1.3.0jsnpmunverified

ts-expect provides a set of lightweight utilities designed for compile-time TypeScript type assertions. Its primary function, `expectType`, takes a value and a generic type, leveraging the TypeScript compiler to ensure the value is assignable to the generic type without performing any runtime checks. The current stable version is v1.3.0, with releases typically adding new utility functions or refining existing type definitions. Key differentiators include its minimalistic approach, relying solely on TypeScript's type system for validation, making it an excellent tool for testing type definitions within a project's codebase. It avoids the overhead of more complex type-checking frameworks like `dtslint` by focusing on direct, in-code type assertions, making it ideal for maintaining type correctness during refactoring or when developing complex generics.

npm install ts-expect
INSTALL
IMPORT
SIG · TS-EXPECT
T
ts-expect
testingjavascriptv1.3.0
Install
Import
Disk
Pass rate
0/ 6
Env Coverage0 / 6
glibc
1822
musl
1822
Install & Compatibility
Where this runs
tested against v? · npm install
Install × environment matrix
Each cell = how many times install + import succeeded across repeated harness runs. Partial = flaky.
glibc = Debian/Ubuntu slim · musl = Alpine Linux
musl
node 18226 runs
build_error
glibc
node 18226 runs
build_error
Code
Verified usage

Verified import paths — ran on the pinned version, not inferred.

expectType
import { expectType } from 'ts-expect';
const { expectType } = require('ts-expect');
Primarily used in TypeScript files for compile-time type assertions. The CJS require pattern is incorrect for its primary usage context.
TypeEqual
import { TypeEqual } from 'ts-expect';
const { TypeEqual } = require('ts-expect');
A utility type used for stricter type equality checks. Cannot be 'required' as it's a type-level construct.
expectNever
import { expectNever } from 'ts-expect';
const { expectNever } = require('ts-expect');
Introduced in v1.3.0 for exhaustive type checks within control flow, returning `never` at runtime and ensuring compile-time exhaustiveness.

This quickstart demonstrates basic compile-time type assertions with `expectType`, strict type comparisons using `TypeEqual`, and ensuring exhaustive handling of union types with `expectNever`, all without runtime execution.

import { expectType, TypeEqual, expectNever } from "ts-expect"; // --- Basic expectType assertions --- // These checks are performed at compile-time by TypeScript. expectType<string>("hello world"); expectType<number>(42); // The following line would cause a compile-time error: // expectType<boolean>("true"); // Type 'string' is not assignable to type 'boolean'. // --- Using TypeEqual for stricter type comparisons --- // TypeEqual is a utility type to ensure two types are exactly the same. interface User { id: string; name: string; } type AdminUser = { id: string; name: string; roles: string[] }; // Expects that User and AdminUser are NOT equal, so asserting 'false' should pass. expectType<TypeEqual<User, AdminUser>>(false); // The following would cause a compile-time error if types were not equal: // expectType<TypeEqual<User, { id: string; name: string }>>(false); // Type 'false' is not assignable to type 'true'. // --- Exhaustive checks with expectNever --- // expectNever is useful for ensuring all cases in a discriminated union or switch statement are handled. type TrafficLight = "red" | "yellow" | "blue"; // Typo: 'blue' should likely be 'green' function getAction(light: TrafficLight): string { switch (light) { case "red": return "Stop"; case "yellow": return "Prepare to stop"; // If 'green' was intended and 'blue' added, this 'default' will catch unhandled types. default: // This line will trigger a TypeScript error if 'light' is not assignable to 'never'. // It helps catch unhandled cases in unions at compile time. return expectNever(light); // Expects 'light' to be 'never' here. } } getAction("red"); getAction("yellow"); // The 'blue' case will cause a compile-time error due to expectNever if it's not handled. // This demonstrates a powerful pattern for ensuring type safety in complex logic.
Debug
Known issues
gotcha`ts-expect` provides purely compile-time checks and performs no runtime validation. Developers expecting runtime assertions will find that `expectType` and `expectNever` do nothing at all when JavaScript code executes.
fix
For runtime validation, use a dedicated runtime validation library (e.g., Zod, Yup) or implement explicit runtime checks alongside `ts-expect` for compile-time safety.
affects: >=1.0.0
gotchaThe `any` type in TypeScript acts as an 'off switch' for type checking. Passing a value typed as `any` to `expectType` will always pass, effectively bypassing the type check.
fix
Avoid using `any` when type safety is critical. Prefer `unknown` when you need a top type and explicitly narrow its type before assertion, or use more specific types.
affects: >=1.0.0
gotchaThere's a subtle but important distinction between `expectType<never>(value)` and `expectNever(value)`. `expectType<never>(value)` is solely a compile-time assertion, whereas `expectNever(value)` also returns `never`, making it suitable for exhaustive checks in runtime code paths (like default cases in `switch` statements) where you want to ensure unreachable code remains unreachable.
fix
Use `expectNever(value)` when you need to return `never` (e.g., throwing an error in an unhandled case), and `expectType<never>(value)` for purely testing that a type resolves to `never` without affecting runtime flow.
affects: >=1.3.0
Errors
Common errors & fixes
Argument of type '"some string"' is not assignable to parameter of type 'number'.
Attempting to assert a value with a type that is not assignable to the generic type provided to `expectType`.
fix
Ensure the type of the value passed to `expectType` is assignable to the generic type. For example, `expectType<string>("hello")` or `expectType<number>(123)`.
Type 'false' is not assignable to type 'true'.
This error occurs when using `expectType<TypeEqual<Target, Value>>(true)` and `Target` is not strictly equal to `Value`. The `TypeEqual` utility resolves to `false`, causing the assertion against `true` to fail.
fix
Verify that `Target` and `Value` are indeed strictly equal in the TypeScript type system. If they are intentionally different, assert `expectType<TypeEqual<Target, Value>>(false)` instead.
Function lacks ending return statement and return type does not include 'undefined'.
When using `expectNever(value)` in a function with an explicit return type, this error can appear if not all code paths explicitly return a value of the declared type. This often happens if `expectNever`'s branch is expected to be unreachable but the compiler still needs a return.
fix
Ensure that `expectNever` is used in contexts where its return value (`never`) aligns with the function's return type (e.g., by throwing an error or in a `void` function). Alternatively, make sure all other branches explicitly return a value matching the function's return type.
Upgrade
Version history
1.3.0latest on npm
Audit
Dependencies

No dependency data recorded yet.

Agent activity
10 hits · last 30 days
node
10
Resources
ts-expect — npm install ts-expect · libregistry