-
-
Notifications
You must be signed in to change notification settings - Fork 67
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comparison to dtslint #10
Comments
From my experience with
|
This module is, however, quite young, it still misses a few features:
expectType<{[key: string]: any}>({foo: 'bar'}); // => OK
// while {[key: string]: any} is definitely not the same as {foo: 'bar'}
expectType<string | number>(1); // => OK
|
I really wish we had this one.
I assumed it was already |
See: #13. :-) It is not enabled by default, but we can discuss this issue there. |
@sindresorhus I was thinking about export type TypeOf<T, U> = Exclude<U, T> extends never ? true : false;
export function test(_: string): void {}
expectType<TypeOf<[string], Parameters<typeof test>>>(true);
expectType<TypeOf<[number], Parameters<typeof test>>>(false); |
expectError<string>(5);
//=> Passes
expectError<string>('🦄');
//=> Expected an error, but found none.
expectError(foo(1, 2));
//=> Passes if `foo` only accepts strings as argument types |
Are there any other things that don't work for you? Please feel free to let me know so I (or we) can fix this. @BendingBender What do you exactly mean with: expectType<{[key: string]: any}>({foo: 'bar'}); // => OK
// while {[key: string]: any} is definitely not the same as {foo: 'bar'} Why aren't these the same? |
I'm missing some context why we need this package. Does your |
It certainly does, just read this issue microsoft/dtslint#191 // dtslint
const o = from([of(1), ['test'], iterable]); // $ExpectType Observable<IterableIterator<number> | Observable<number> | string[]>
// tsd-check
expectType<Observable<IterableIterator<number> | Observable<number> | string[]>>(from([of(1), ['test'], iterable])); Already explained by @BendingBender, you can't make typo's because the TypeScript compiler will tell you it's wrong. Secondly, And thirdly, one I find quite nice to have, is that when writing tests, the TS compiler already gives you feedback if you do something wrong. expectType<string>(1); This will already be marked with a red line by your text editor because the compiler detects a type mismatch. This is not the case with So yes, in my opinion, this library has benefits over |
Just to be clear I didn't mean to attack you. I think all of those points are perfectly valid. I just think it's very important to list related work in packages and how it compares. Otherwise the choice for or against a package becomes arbitrary. |
Do you think it would help if we documented in the readme? |
If we document this, I don't want it to become |
What I mean is that the type const foo = () => 'foo';
expectType<string | undefined>(foo()); This will pass. The problem is that actually I wanted to assert that |
I'm looking to try this library out, and can't figure out if there's good support for the "sufficiently narrow" test cases I typically write when working with I usually rely on this aspect of
i.e., if I have a function foo(); // $ExpectType Promise<[number, number]> and I'd be good to go, since I'm asserting against the stringified type return value of In this library I could do expectType<Promise<[number, number]>>(foo()); But it also would pass if I introduced a bug causing As a result, the following (potentially undesirable) changes to function foo(): Promise<[number, any]>;
function foo(): Promise<[any, any]>;
function foo(): Promise<any>;
function foo(): any; Are there plans to handle any cases like these? Do consumers of this library typically just worry about testing that types are sufficiently wide and don't care as much about them being sufficiently narrow? |
@mike-north Just made a PR to improve type assertions: #21. |
Strict type assertions will be available somewhere this weekend. Have to wrap little things up and then it's good to go. The benefit in tsd versus dtslint is that dtslint uses the string representation of the type. This means that Tsd checks assignability on type level, which means that we don't have that problem 🎉 . Keeping you guys posted when I release this feature. |
I just released @BendingBender I wasn't sure what should happen in case of expectError<string | number>(add(1, 2));`
I wasn't sure about this and like some feedback on this topic. |
A few more points to contribute to this comparison:
map(['a', 'b', 'c'], (
x, // $ExpectType string
i, // $ExpectType number
xs // $ExpectType string[]
) => 0); To do the same thing with tsd you need to add a function body: map(['a', 'b', 'c'], (x, i, xs) => {
expectType<string>(x);
expectType<number>(i);
expectType<string[]>(xs);
});
@BendingBender makes a great point about misspelled Getting feedback from tsc in your editor is nice. Since dtslint is built on tslint, there's no reason you couldn't get it to do the same thing. But I'm not aware of anyone doing that. At least to me, a linter does feel like the right tool to do this since it's a bit different than ordinary TypeScript type checking (two-way assignability checks for tsd, comparison of types as strings for dtsint). There's no reason you couldn't build an editor plugin for tsd, either. The point about My 2¢! |
Thanks for sharing this @danvk! |
I'd like to know how your library compares to
dtslint
. As of right now it looks like I can achieve the same withdtslint
's expect rule andtslint
.Do you have any issues with
dtslint
that you want to fix or features that you want to add?The text was updated successfully, but these errors were encountered: