-
Notifications
You must be signed in to change notification settings - Fork 3k
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
Losing type inferences in marble tests #1633
Comments
/cc @staltz for visibility, also @david-driscoll . I've quickly tried if it's possible to use ambient declaration to test helper interfaces, but that wasn't successful since dependent types ( @staltz for asking idea if we can solve this in |
I don't understand what does jsdoc have to do with the marble tests. Can't we make |
: no, this isn't about it. Do you remember original refactoring was importing test helper directly like import {hot} from ...
hot(); ? it's transpiled by compiler something like var hot_1 = require(...);
hot_1(); so |
Oh I see. Can't we declare the types of those functions in each file? Like declare hot: string => Observable<any>; (Just an example, not sure if that compiles) |
Can be, but I'm feeling that'll be too much repeated code. (Should import |
Can you build it with a custom typings file that includes these definitions? |
: bit doubt about it. First, can't create external type definition since this issue is result of avoid external import ( For now most realistic approach seems @staltz 's suggestion above even it has some amount of duplicated code around test cases, still I'd like to look for other alternative bit more. |
Something like this won't do?
I'm not sure I'd agree that handcrafting a typings file with ~8 definitions in it is going to be more work than adding definitions to every spec file. |
Maybe I'm not understanding the issue here, though. |
: it's not ~8, unfortunately. Let's say one signature as example:
now need to create interface
requires handcraft of Still this is based on my experiment and there might be better way to resolve this.. (:eyes: to @david-driscoll :) ?) |
Is this really a "big deal", though? I mean, is this worth all of the trouble? Is the real answer just to update our test helpers to be a TypeScript module and be more explicit about the usage? |
: I'm not considering this as serious problem, though it's bit unfortunate we've moved all test cases into typescript and losing one of benefits for dogfooding type verification.
: That was my original intention and I believe that's simplest solution. What we're trying to solve in here is bending module system in our way to bypass some issues ( I'd consider this as low-priority, good-to-have goals for now. But still believe eventually need to be resolved some way. Best scenario will be documentation system can understand original TS code as-is instead of lean on transpiled results, but that seems not likely to happen with jsdoc. |
After experiencing regression issue like #2163 and now library try to follow semver strictly, I started thinking this might need to be looked again. Originally test case supposed to serve as validating type definitions as well, but currently does not by due to this issue since all of |
One last thing for this issue is enabling
Thanksfully default generic will be introduced soon enough (microsoft/TypeScript#2175 (comment)), once we bump up compiler version with supported we can have like |
This is somewhat resolved and while there is lot to go, issue itself can be closed. Individual issue can be dealt via PR / separate issue. |
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
RxJS version:
master
Additional information:
Currently to enhance
jsdoc
test code readability, test scheduler interface is not being directly imported but accessed globally with implicit ambient declaration, sohot
orcold
observable generated does not support any type inference toObservable<T>
This is somewhat problem since all unit test cases are intended to be used as type definition test cases too, which current test cases are losing its benefit in lot of cases.
The text was updated successfully, but these errors were encountered: