-
Notifications
You must be signed in to change notification settings - Fork 106
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
Type Defintions: Clock returned from install is missing uninstall property/function #356
Comments
It also seems to miss some other properties like Due to the nature the types are defined it is also not possible to declare the type of a variable without installing it too: // not possible for later installation e.g. in a beforeEach(), because there is no type definition name "FakeClock" or any other:
let fakeTimer: FakeClock;
// have to do it like this and install it immediately. It is returning the type object directly instead of a named type referencing the object like in the example above.
const fakeTimer: FakeTimers.install(); |
You can use let fakeTimer: ReturnType<typeof FakeTimers.install> However, having a dedicated Clock type similar to the one that the DefinitelyTyped type definitions would be preferable imho. @fatso83: Is there a rationale behind generating types from JSDoc definitions? Is there anything that triggered this move away from making TypeScript users use the DefinitelyTyped types? In my opinion you will be fighting an up-hill battle and have more maintenance effort with trying to make JSDoc types work. While I haven't looked deeply into how JSDoc comments are translated into TypeScript type definitions, I can imagine that the result will be inferior to manually written definitions (like from DefinitelyTyped) or type definitions that are generated from TypeScript code. |
I never minded the external definitions (I even fixed a few errors in the As we are not going to redo these projects in TypeScript, but we do want better docs, this has the potential of generating types that are up to date as the project hums along. When I have looked at various definitions that have been generated in the DT packages, I have seen definitions for APIs that we have long since deprecated and removed, and docs generated directly from the package would have a better change of taking care of that. The docs would also have the upside of staying in sync with the version that is used, which is non-trivial using DT.
@mroderick You are better equipped to answer this. |
Should probably set up Some feature parity with DT should probably have been aimed for before releasing, but what's done is done 😀 |
|
See: |
We can make up to date type definitions available to the TS community and save effort. Perhaps we jumped the gun and released the files too soon. I'm hoping that the TS/DT community will see this in a kind light, and help bring us up to parity with the DT types by contributing to the documenation effort For those that have gotten bitten by the immature |
Is this something you are strict on this? I mean the file is not too big, we could rewrote it in TS, not strictly, without big issues. |
@bodinsamuel Yes, we're strict on this. It's not about effort or file size. |
FakeTimers version : 7.0.2
Environment : Node.js
Example URL : https://codesandbox.io/s/sharp-fast-7zwis?file=/src/index.ts
Other libraries you are using: TypeScript (4.1.3)
What did you expect to happen?
When storing the return value of
install
in a variable, theuninstall
function helps uninstalling the fake clock again from the environment.Note: I'm currently limited in time, otherwise I would submit a PR which adds the types from DefinitelyTyped as an initial (tested and working) version for the types.
What actually happens
When using TypeScript, the return value of
install
does not include theuninstall
property.How to reproduce
You can check an example here: https://codesandbox.io/s/sharp-fast-7zwis?file=/src/index.ts
The text was updated successfully, but these errors were encountered: