Assertion functions don't work when defined as methods

TypeScript Version:

3.9.0-dev.20200220

Search Terms:

assertion signature

Code

type Constructor<T> = new (...args: any[]) => T

let str: any = 'foo'

str.toUpperCase() // str is any

function assert(condition: unknown, message: string = 'Assertion failure', ErrorConstructor: Constructor<Error> = AssertionError): asserts condition {
    if(!condition) {
        throw new ErrorConstructor(message);
    }
}

assert(typeof str == 'string')

str.toUpperCase() // str is string

class AssertionError extends Error { }

class Assertion {
    assert(condition: unknown, message: string = 'Assertion failure', ErrorConstructor: Constructor<Error> = AssertionError): asserts condition {
        if(condition) {
            throw new ErrorConstructor(message);
        }
    }
}

let azzert = new Assertion().assert

let str2: any = 'bar'

azzert(typeof str2 == 'string')  //error 2775

str2.toUpperCase() // str2 is any

Expected behavior:

Assertion functions are usable as methods of a class

Actual behavior:

Assertions require every name in the call target to be declared with an explicit type annotation.(2775)
'azzert' needs an explicit type annotation.

Playground Link:

https://www.typescriptlang.org/play/?ts=3.9.0-dev.20200220&ssl=1&ssc=1&pln=33&pc=34#code/C4TwDgpgBAwg9gOwM7AE4FcDGw6oDwAqAfFALxQIQDuUAFAHSMCGqA5kgFxRMIgDaAXQCUZEgQCwAKCkAbCMCgpUXHiDJQA5ADM4cDVKlL6OAKphIqGEyQRaIgPT3FaKAEsk3Xgclb0CbK6I3Eg2qMC0mIgAJq7AgQhcfgDWCHBUCAA0UAC2ECFMrBBcSq4IrOoaAIIhEGHxUFpMrjLoqBAaWQCiqKi48MhoWDjKsIhKQ7h43b2oJOTVoXGI07hCKjVhHpEIMUsIUADeUlAnblq0AITbu-EiR5Knj1DAABa9NJQ0K5Zjg9i4tFy+UKQgA3MdTgBfKTQ6SSayLWigSBwLTOVBkcgaEplDRCbxGUzmWpWGx2KCOdFuDw41jeTAyBFQBa1PbfKAQAAewAgOw87IOUFhUgZTJZdSC90eCNZEWisXiiQQKTSmRyeSQBSK6NK5Sx4r2DSaLTaHSg33643+I0tf2GUx6uDmzI2bMdqDWwUWW3lhqlTxOrnO1wViDuEIDj1e7wo1HN7ttGGtgI1WrBEaesMesOFkjkCiYAC9C6z1J8XYt4nZ6DKwt58+iAEwqXgVABGLH0cKLJbCSPAEFRTcxmlpeIp9lqMygjYA7LOAKwEtCN4xwMwWUm2BxOJSN6meEBAA

Related Issues:

Perhaps this a design limitation per the following PR?

#33622
#33622 (comment)

Assertion functions always need explicit annotations. You can write this:

let azzert: Assertion['assert'] = new Assertion().assert;

Ryan Cavanaugh (@RyanCavanaugh)

Ryan Cavanaugh (@RyanCavanaugh) Can you explain in a little more detail? I don't understand how to resolve the issue.

This also is failing with the same error:

import * as assert from "assert";
export function exists(value: unknown): asserts value {
  assert(value);
}

export default {
  exists
};

Using:

import assert from "./assert";

assert.exists(true); // error ts(2775)

How does the exists function not have an explicit annotation? Or what can I do to resolve it in this case.

If I just export the function as non-default and do the import as import { exists } from "./assert" then it works but I'd like to have them grouped on the object assert.xyz.

Justin Chase (@justinmchase)

Justin Chase (@justinmchase) , @amber-pli

Create a let/const/var and assign it the assert function you imported. Give that variable an explicit type like in the example provided by Ryan Cavanaugh (@RyanCavanaugh) .

I guess whats confusing me is that he said:

Assertion functions always need explicit annotations

But I believe in my code the function does have an explicit type annotation, yet its not working. Are we saying there is a bug and that the variable assigned to the function needs the explicit type as well?

Justin Chase (@justinmchase)

Justin Chase (@justinmchase) The type needs to be explicit, it's not a bug
#34523
#34596

Ok, one last time, I swear I'm not being intentionally obtuse but I think I'm homing in.

I think my confusion is because, to my understanding, this function has an explicit type:

export function exists(value: unknown): asserts value {
  assert(value);
}

So when you say the type needs to be explicit its boggling my mind because I don't get how it couldn't be explicit.

But now, I'm wondering if you don't mean the function's type but the type of the argument needs to be explicit? As in the value: unknown is the issue? It needs to be non-generic and not something such as any or unknown? Is that what you mean?

Justin Chase (@justinmchase)

Justin Chase (@justinmchase) explicitly give it a type where you imported it.

Justin Chase (@justinmchase)

Justin Chase (@justinmchase) I think the part that is boggling your mind is that the message isn't clear about what exactly doesn't have an explicit type. You quoted this code, which clearly does have an explicit type:

export function exists(value: unknown): asserts value {
  assert(value);
}

But when you used it, you imported it like this:

import assert from "./assert";

assert.exists(true); // error ts(2775)

The 2775 error you are getting on that line is not about exists needing an explicit type, it's about assert needing one. You can verify this by importing exists directly:

import { exists } from "./assert";
exists( true ); // works without the error.

So the error isn't telling you about problems with exists, it's telling you that your default export needs to be explicitly typed:

const defaults: {
  exists( value: unknown ): asserts value;
} = {
  exists,
};

export default defaults;

It isn't entirely clear to me why that is the case, and it seems that making the error message clearer about where exactly the problem lies was discussed and rejected.

What I have found can work to avoid having to repeat the typings twice is to move the actual assertion functions into a separate file and then re-export them:

export * from './real-assertions';
import * as assertions from './real-assertions';
export default assertions;

I'm also not entirely clear on why this works, but it seems like it does..

Ok thanks, I'll try it out!

It does seem like there is a bug in here but I'll settle for work arounds for now.

As a prime example where you would expect this to work, but it doesn't—in a way that seems to me at least to pretty clearly be a bug—is namespaces.

For backwards compatibility, Ember's types have both modern module imports and re-exports from the Ember namespace. So we have:

export function assert(desc: string): never;
export function assert(desc: string, test: unknown): asserts test;

import { assert } from '@ember/debug';
assert('this works', typeof 'hello' === 'string');

And we also re-export that on the Ember namespace, with a re-export like this:

import * as EmberDebugNs from '@ember/debug';

export namespace Ember {
    // ...
    const assert: typeof EmberDebugNs.assert;
    // ...
}

const { assert } = Ember;
assert('this FAILS', typeof 'hello' === 'string');

'assert' needs an explicit type annotation.

I understand the constraints as specified, and I'm afraid I must disagree with the team's conclusion about this error message—

We discussed in the team room and agreed that the existing message is fine, so I didn't change it.

—seeing as it took me about half an hour to finally find my way to this thread and understand the problem, and another half an hour to figure out how to rewrite our DefinitelyTyped tests to continue handling this! 😅

For the record, if anyone else is curious, this is how I'm ending up working around it for the types PR I'll be pushing up shortly:

const assertDescOnly: (desc: string) => never = Ember.assert;
const assertFull: (desc: string, test: unknown) => asserts test = Ember.assert;

(I'm also going to have to document that or be ready to explain it, though gladly basically none of our TS users are likely to be doing this.)

Ryan Cavanaugh (@RyanCavanaugh)

I tried to include an assertion function as part of the exports for an inner module in one of my libraries and was heartbroken to find that, while I could use it perfectly within the module, I could not use it when referencing it from outside via the module namespace. Ryan Cavanaugh (@RyanCavanaugh)'s answer was a godsend!! Thank you so much!

Here's what I was doing:

Project1::src/Http.ts

export function assertThing(thing: any): asserts thing is string {
  // ...
}

Project1::src/index.ts

import * as Http from "./Http";
// ....
export { Http, /* .... and other things .... */ }

Project2::src/Functions.ts

import { Http } from "project1";

export const handler = (thing: any) => {
  Http.assertThing(thing);
  // ....
}

I was getting the error in the original post because of this, and I couldn't get past it. I successfully utilized Ryan's solution by doing this:

Project2::src/Functions.ts

import { Http } from "project1";

const assertThing: (typeof Http)["assertThing"] = Http.assertThing;

export const handler = (thing: any) => {
  assertThing(thing);
  // ....
}

While a little awkward, this is a total life-saver and has allowed me to successfully use this wonderful assertion functionality without limitation. (Note that it was necessary to use the (typeof Http) notation because typescript complained that namespaces can't be used as types.)

Anyway, just wanted to add this for anyone who may be struggling with something similar. Thanks again for the tip, Ryan Cavanaugh (@RyanCavanaugh)!

* glob needs adding as a dependency

For what it's worth this has made the Assert library usable again when checking JavaScript with Typescript.

const Assert = /** @type {typeof import('assert')} */(require('assert'))

All the type errors reported about non-explicit types are gone (thankfully).

Note that if you need method overloading semantics your workaround will need to create an interface:

interface InvariantStatic {
  (condition: false, reason: string): never;
  (condition: any, reason: string): asserts condition;
}

declare let invariant: InvariantStatic;

My use case when it breaks:

scoped 'logging' utility that adds prefix to logs or asserts simply to save me keystrokes and improve dev-experience when debugging or analyzing complex code scenarios

Example:

const scope = createScope("Foo");

scope.assert(false, "Nope"); // <— expected: throws error `[Foo] Nope` (saves me `[Foo] ` keystrokes (potentially x20 times in some examples)
scope.log("hello"); // <— expected: logs "[Foo] hello"
// etc.

Thus my assert is a method 'by-design' and I want it to be this way.

But I cannot use that due to mentioned TS error:

scope.assert(false, "Foo"); // TS: Assertions require every name in the call target to be declared with an explicit type annotation.
// Same for
const { assert } = scope
assert(false, "Foo");
// or
const assert = scope;
assert(false, "Foo");

The only way to make it work is:

const assert: (input: unknown, message: string) => asserts input = scope.assert
assert(false, "Foo"); // TS does not complain and works

// or
type Assert = (input: unknown, message: string) => asserts input;
const assert: Assert = scope.assert;
assert(false, "Foo"); // I can now re-use `Assert` type, but it is still very manual and misses the point of effective logging / asserting / debugging utility

but doing it this way (explicitly having to assign the type to assert totally misses the point which is my case was - make DX of writing debugging/assert messages easier)

Also, error message is not really friendly. It is hard for me tu guess what exactly TS wants me to do, forcing to Google it and doing a bit deep read (like this issue) to understand it.

It also seems like some internal TS-limitation leaking, rather than some reasonable design decision that makes sense forcing me to not doing what I want to do.

Thus something like :

Typescript currently does not support assert functions that are not explicitly typed at every step. Thus, assert function cannot be part of any object

would be way more friendly and save me some time.

Or even more friendly:

interface Logger {
  assert(input: unknown): asserts input; // <— TS Error: Assert functions cannot be part of interfaces
}

this way I would know it earlier and in well-targeted place. This way I know my idea of putting assert inside object is not possible, rather than later thinking I use it in a wrong way.

I am also facing this issue any update when this bug will be resolved?

Just throwing in my two-cents because I got struck by this annoying and very unhelpful bug wording today..

My 'branding' string code.

export type DodiAttributeCodeType = string & { _type: 'DodiAttributeCode' };

/* Delcare type to get around TS Bug */
type DodiAttributeCode = {
  guard(str: string): str is DodiAttributeCodeType;
  parse(str: string): DodiAttributeCodeType;
  assert(str: string): asserts str is DodiAttributeCodeType;
};

export const DodiAttributeCode: DodiAttributeCode = {
  guard(str: string): str is DodiAttributeCodeType {
    return !!str; /* some complex test */
  },
  assert(str: string): asserts str is DodiAttributeCodeType {
    if (!DodiAttributeCode.guard(str)) {
      throw new Error();
    }
  },
  parse(str: string): DodiAttributeCodeType {
    DodiAttributeCode.assert(str);
    return str;
  },
};

import { DodiAttributeCode, DodiAttributeCodeType } from '@core/types/DodiAttributeCode';

const a = 'hello';
const b: DodiAttributeCode = a; // TS error 2322, string not valid
DodiAttributeCode.assert(a);
const c: DodiAttributeCode = a; // TS loves it.. Time to do real work now.

Assertion functions always need explicit annotations. You can write this:
let azzert: Assertion['assert'] = new Assertion().assert;

Thanks for the clear explanation, this is a strange behavior from typescript. Got stumped by this error today.

Really strange behavior

const value: unknown = 0

const foo = (value: unknown): asserts value is number => { }
foo(value) // error
value // unknown

const foo_: typeof foo = foo
foo_(value) // ok
value // number

const value: unknown = 0

const foo = {
    bar(value: unknown): asserts value is number { }
}
foo.bar(value) // error
value // unknown

const foo_: typeof foo = foo
foo_.bar(value) // ok
value // number

* glob needs adding as a dependency

Also chiming in that I ran into this bug in 4.9.4. I am saddened to hear that the typescript devs believe that this behavior is somehow working as intended.

Fwiw, if t.assertSomething(val) reports that error because t is not explicitly typed, you can solve it by doing

const t2: typeof t = t;

t2.assertSomething(val);

so that t2 is explicitly annotated as having its own type.

While I can at least understand the decision to consider this working as intended, the error message you get only makes sense after you discover the solution to the problem, which is not an ideal trait in an error message.

I think everybody would prefer that asserts and is behave the same in the context of they definition. The current situation:

declare function makeStruct(): {
   assert(subj: unknown): asserts subj is string
   guard(subj: unknown): subj is string
}

const struct = makeStruct()

declare const subj: unknown

// ts-error:
// "Assertions require every name in the call target to be
//  declared with an explicit type annotation. 10:1:416 typescript2775"
struct.assert(subj)

// No such problem with `guard`
if (struct.guard(subj)) {
  subj // `string` as expected
}

The current restriction is highly unintuitive and reduces ts community ability to create nice assert method for schema dependent parsers/validators.

For example we could have assert method in zod library structs and typeguard unknown data like this:

import z from 'zod`

declare const subject: unknown

z.string().assert(subject)

subject // `string`

Ryan Cavanaugh (@RyanCavanaugh)

Ryan Cavanaugh (@RyanCavanaugh) is there somewhere to view the 'completed' work?

The bulk "Close" action doesn't let you pick which "Close" you're doing.

Design Limitations aren't supposed to be left open - it means we're not aware of any plausible way to address them.

Navigation Menu

Repository navigation

Assertion functions don't work when defined as methods #36931

11 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Assertion functions don't work when defined as methods #36931

Description

Activity

RyanCavanaugh commented on Feb 21, 2020

justinmchase commented on Apr 28, 2020

mlhaufe commented on May 6, 2020

justinmchase commented on May 6, 2020

borisyordanov commented on May 6, 2020

justinmchase commented on May 7, 2020

mlhaufe commented on May 7, 2020

jasonk commented on May 25, 2020

justinmchase commented on May 26, 2020

chriskrycho commented on May 29, 2020

kael-shipman commented on Sep 9, 2020

dschnare commented on Nov 25, 2020

11 remaining items

conartist6 commented on Oct 11, 2021

pie6k commented on Jan 31, 2022

atulgpt commented on Feb 6, 2022

WORMSS commented on Mar 17, 2022

jeremy-rifkin commented on Apr 6, 2022

nomadshiba commented on Feb 1, 2023

cmdruid commented on Jul 12, 2023

nicolo-ribaudo commented on Aug 16, 2023

pckilgore commented on Sep 20, 2023

incerta commented on Feb 16, 2024

WORMSS commented on Feb 24, 2024

RyanCavanaugh commented on Feb 24, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions