Closed tbroyer closed 8 months ago
As a workaround, I can call the decorator myself, but that defeats part of the goals of the tests as I now set explicit types inferred from what I think TypeScript will use, rather than let TypeScript use whatever types it expects.
import { expectError } from "tsd";
class Base extends HTMLElement {
foo() {}
}
const classDec = <T extends new (...args: any[]) => Base>(
value: T,
context: ClassDecoratorContext<T>
) => {
return class DecoratedClass extends value {};
};
() => {
class Test extends Base {}
classDec(Test, {} as ClassDecoratorContext<typeof Test>);
};
expectError(() => {
class Test {}
classDec(Test, {} as ClassDecoratorContext<typeof Test>);
});
expectError(() => {
class Test extends Document {}
classDec(Test, {} as ClassDecoratorContext<typeof Test>);
});
expectError(() => {
class Test extends HTMLElement {}
classDec(Test, {} as ClassDecoratorContext<Test>);
});
expectError(() => {
abstract class Test extends Base {}
classDec(Test, {} as ClassDecoratorContext<Test>);
});
FWIW tsd
is matching errors using a predefined list of codes. Users must open PRs to add the missed codes one by one. For example, see #205
It appears that most of the error codes here fall into what tsd considers "syntactical errors" (< 2000): 1238 to 1241, 1249, 1270 and 1271, 1278 and 1279, and 1329.
Not quite sure how to handle that (I'm trying to prepare a PR, with tests!)
Here is the place to distinguish between semantic and syntactic errors (if there is an intention to keep them distinct, why to pour everything into one list?):
As an example, in forked tsd-lite
(it is not maintained anymore), I was passing only semantic errors to evaluate in the matchers:
I'm writing a helper library around decorators (standard ECMAScript ones, as supported by TypeScript 5+ and
@babel/plugin-proposal-decorators
) and have been unable to test errors when applying them.Here's a self-contained reproduction:
classDec
can only be applied to a concrete class extendingBase
, so the anonymous class extending nothing,Document
,HTMLElement
, or an abstract class are errors.This however fails with:
Same result as if I omitted the
expectError
from the file.