-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
ci(): TS test suite #8394
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
base: master
Are you sure you want to change the base?
ci(): TS test suite #8394
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
READY!
TS tests fail as they should
I think we ought to add a module
field to package.json
and change the index file and exports to fix that
Build Stats
|
I tried to resurrect and test this PR but now rollup doesn't allow to handle the build output destination as you wanted, this was a breaking change of Rollup 3 |
if i clear the dist folder and i let it run in the dist folder, then it can run. It can't run in cli_output |
Motivation
#8392
#8297 types are complex. That introduced the need to test typing, see comments.
I worked on types. And then I had to test it comes out as I expected it.
So I found myself writing calls to the animate function to see if I wrote the complex type correctly.
Instead of writing and deleting why not have a dedicated place that I can work on, comment and discuss in a PR and make sure it behaves as I expect it to.
Then, regardless, I found that the entry point to the repo is not typed. A good case for why ts tests are crucial.
Research
dtslint
,tsd
, see below// @ts-expect-error
and test if the file compiles.@definitelytyped/dtslint
suggested by official TS but has limitation since it does a string comparison of the compiler returned type so
a | b != b | a
and typos in test files will f*** us overSeems to run only on declaration files so is completely worthless
js test suite with
expectType
,expectError
etc., suggested by official TSCan only assert a value, not params. so is worthless on its own
js test suite, seems not popular yet
type assertions + js assertions, looks good
unrelated to testing
Findings
// @ts-expect-error explanation
to assert an error and test for file compilationconditional-type-checks
|tsd
=>conditional-type-checks
wins since it is more flexible and accurate (see playground below) and allows testing function parameters and whatever@definitelytyped/dtslint
is useless