-
Notifications
You must be signed in to change notification settings - Fork 1.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
Update the type definitions for the k6/* APIs #929
Comments
I tried it using
The project looks a good start and it should not be difficult to iterate it. I am in favor of completing the |
It seems like we'd have to more carefully comb through the existing type definitions, since they contain some inaccuracies. As mentioned in #1041 (comment), |
I'm working toward this in |
Made a submission to A little example code. /// <reference types="k6" />
import { Response, get } from 'k6/http'
import { Selection, TitleElement } from 'k6/html'
export default function () {
const response: Response = get('http://httpbin.org')
const document: Selection = response.html()
const title: TitleElement = document.find('title').get(0) as TitleElement
console.log(title.text())
} |
Looks like these types were quickly reviewed and merged DefinitelyTyped/DefinitelyTyped#36432. The npm package is already published: The reviewer had a nonblocking concern. Opened DefinitelyTyped/DefinitelyTyped#36473 to address it. |
Thanks! 🎉 I skimmed through the PR, and yeah, the type system seems... interesting 😄 @mstoykov, @bookmoons, @robingustafsson: do you think it's worth adding a line in |
Great! 🎉 I think that we should do both ;) |
Agree with @mstoykov, let's do both :) |
Created #1063 😄 Closing this, since it seems done. |
Thanks guys. Looks like that final update DefinitelyTyped/DefinitelyTyped#36473 was also merged. |
@bookmoons, thank you for working on this issue. I have tested how
@na, we have previously talked about the challenges of having the docs up-to-date. |
Nice bug report. Will look into it. |
Re-opening issue to be able to post the bounty 🙂 |
@ppcano yeah, I guess it makes sense to at least have short descriptions of some of the most used functions, maybe as a separate issue/bounty? But as you know, I'm very leery on further fragmentation of the k6 docs - having the same things in multiple places makes synchronization super difficult... |
I think this is a limitation of the autoimport extension. Tried it with another structured package and it also doesn't seem to find things. npm install --save @types/d There's a function I could take up adding descriptions under an enhancement issue. Wonder if there's a way to generate docs from the declaration files. Get it all in one place. |
@bookmoons For context, I don't know much about There were a few
First, I used auto-import on different modules when using the Ember Type definition and it works with classes
There are no many Type definitions with multiple namespace/modules, but
I can help with the testing or any other thing. |
Will look into this. That |
It seems autoimport only sees things that are loaded by the index file. Adding simple imports for everything to index makes it work. import './crypto';
import './encoding';
.. Opened DefinitelyTyped/DefinitelyTyped#36586 to deploy this. |
That update has been published DefinitelyTyped/DefinitelyTyped#36586 (comment) |
@bookmoons Please, could you check the Type definition of the default module for the
|
Had a look at this. Think I'd have to do it under another issue. I think there's a way to make it happen but I'd have to investigate to find something that works with TypeScript and DefinitelyTyped conventions and doesn't break the destructuring imports. Potentially restructure the modules to make it possible. |
Closing this, since the type definitions are done. Opened #1071 to track the auto-import improvements. |
As @marklagendijk noted in slack, there's apparently a types package for k6: https://www.npmjs.com/package/@types/k6 (the actual files are located here). According to him it's not 100% complete, so it has to be checked and likely slightly improved.
We should probably also try to make sure we update those definitions if we add new k6 APIs... Not sure how possible it would be to automate that task, as some sort of a new CI check or unit test that complains if something is missing or mismatched... Likely not easy at all, so we may have to be satisfied with a single reminder in
CONTRIBUTING.md
stating something like "if you're changing the APIs, make sure you update this repo as well"...The text was updated successfully, but these errors were encountered: