ts-extras

Description and currently accept any type: export function assertPresent(value: T, message?: string): asserts value is NonNullable export function assertDefined(value: T | undefined, message?: string): asserts value is T This means the following is allowed and is a no-op at the type level: const s: string = 'hello'; assertPresent(s); // OK, but unnecessary assertDefined(s); // OK, but unnecessary I would expect these functions to only accept types that can actually be nullish, so the call is rejected when the value is already known to be present/defined. That would catch accidental no-op assertions at compile time. Proposed signature Something like: export function assertPresent( value: null extends T ? T : undefined extends T ? T : never, message?: string, ): asserts value is NonNullable export function assertDefined( value: undefined extends T ? T : never, message?: string, ): asserts value is NonNullable Or the rest-parameter version for slightly more reliable inference: export function assertPresent( value: T, message?: string, ..._mustBeNullish: null extends T ? [] : undefined extends T ? [] : [never], ): asserts value is NonNullable Behavior Why Makes the intent of the call clearer (you only assert when the type system thinks it might be missing). Catches accidental calls on already-narrowed values. Aligns with the common expectation that an assertion function is only useful when the type can still be nullish. Alternatives considered Leave the signature as-is and rely on a custom ESLint rule (more friction for consumers). Only document the recommended usage (doesn’t prevent the no-op case). Happy to open a PR with the change + tests if this direction looks good.