typescript tests #3273
Comments
|
DT uses their own tool dtslint... but they point to tsd to use elsewhere, should be easy enough to set that up... do note that on DT the tests are written alongside the types so everyone else works on the tests too. Off-topic but... not too sure about using such an old version of the types, there's a huge amount of work on the types that will need to be carried over... it's probably easier/better to start with the latest version and gradually remove ts-toolbelt |
|
There was a discussion with @sandersn from the TypeScript compiler team about an issue we had with dtslint on Discord. Long story short: While dtslint is quite useful to tests types, the way its done is also quite primitive. Basically all it does is compare the string output of the generated types. But to dtslint Ideally we'd have a tool that uses the actual TypeScript compiler to check types. Is anyone aware of any such tool? |
|
Another idea: have a file that has some pseudo TypeScript code, over which we let /// Pseudo code
CompareTypes<string, string> // this is fine
CompareTypes<string, number | string> // this throws an error |
|
re: checking types, that would be tsd, no? |
|
re: the file with pseudo typescript code, that's good and all but we'd lose the ability to check error cases... which i feel would make the tests a lot less useful |
|
@somebody1234 ah yes tsd looks great at first glance. Also you are absolutely right about the error cases. But maybe we can mix different approaches? On the other hand: what always bothered me was, that you were just checking that there was an error, not where or which. So these tests always seems very prone to be false positive to me. |
|
yeah... too bad neither ts-expect-error nor tsd let you specify specific errors... :( could maybe fork tsd to support that i guess? |
|
Now that we have the file structure in place, I think this would be a good next issue to tackle. Would anyone like to work on it? @essenmitsosse ? @somebody1234 ? As mentioned in the post at the top, for the initial PR probably just the framework and a small number of functions would be good. |
|
@kedashoe im still on parental leave for the week but will have a look once I'm back. |
|
Alright #3283 has been merged in.. anyone have any thoughts on how we should proceed here? Probably making 270ish issues for each function is not the way to go |
|
We can do checklist for every function. Ramda has its own tests. As an idea we can change some of them gradually to typescript probably? Some part of them(not sure we can change all due to placeholders and curring). |
|
@valerii15298: I think I would have an issue with changing the current tests to TS. Bringing the TS typings in-house is a fine idea, so long as we have people willing to support it. But that won't change the fact that this is a JS library, and it should always remain usable and understandable to those who know JS but not TS. For separate reasons, I don't want to change the tests overmuch before we reach |
Ya I think this is probably the way to go. I'll update the top post in this thread with a checklist at some point today. |
|
re: porting js tests to ts in other words - the js interface is intended to be robust; the ts interface is intended to prevent you from shooting yourself in the foot (imo) |
|
ok I've attempted to make a list of all .d.ts files in /types in the top comment. Everyone feel free to start grabbing your favorites to add tests for 😛 I'll make a separate issue for src files missing an accompany type file (not that many). |
|
Maybe then just check js tests and grab from them what is usable for typescript tests. I mean there can be some use cases with js that we wanna ensure work with TS as well🤔 |
|
When we implement ramda apis' types and their tests, we should also focus on practical programing situation, not only just check the types' correctness, but also usable and composable. Otherwise, we only output something looks good, but not so useful for people in real work, such as this issue describes: ramda/types#118. |
|
I want to use |
.d.ts files in ./types needing test coverage:
I think tests would be a great place to start. That way we can be more confident about everything else we do. @somebody1234 , I know you mentioned working on the tests in DT, would you be interested in working on the initial PR for that here? The smaller the better, maybe the framework and then the tests for 2-4 functions?
The text was updated successfully, but these errors were encountered: