-
Notifications
You must be signed in to change notification settings - Fork 761
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
[WIP] 🌟 New: Adds TypeScript definition generation #386
base: master
Are you sure you want to change the base?
Conversation
I like the PR but don't quiet understand why all the JSDoc needs to be touched to add typing support. Also when I copy the files into my node_modules folder (manually since its not yet in the repo), the axios. namespace gives me errors all over the place. How did it look like for you @Aendrew ? |
I looked at this but it's a lot more work that I expected. I resolved the merge conflict anyways. @Aendrew please merge my PR to your fork so if someone wants to pick it up they can: aendra-rininsland#1 |
Sorry for the really slow response to this issue! @pascalwhoop I'm using JSDoc to generate the TypeScript definitions, and Axios returns a different Promise interface from the standard NodeJS promise. There are a few others that have been changed to allow tsd-jsdoc to properly generate interfaces. @mohsen1 Cheers, thanks for doing that! I'll try to review and merge that sometime soon (ideally tomorrow but have been rather busy as of late). tsd-jsdoc has released a new version and I plan to pick this up again shortly. Hopefully the new version will resolve some of the issues with interface generation that resulted in me having to tweak the JSDoc more than I'd have liked. |
I was trying to use the generated .d.ts file directly in my project. It seems that all references to Those axios related typings are broken since [email protected], which is the version I got when I installed [email protected] with yarn. |
lib/Requestable.js
Outdated
* @param {(Object|true)} result - the data returned by the API or `true` if the API returns `204 No Content` | ||
* @param {Object} request - the raw {@linkcode https://github.com/mzabriskie/axios#response-schema Response} | ||
* @param {axios.Response | boolean} result - the data returned by the API or `true` if the API returns `204 No Content` | ||
* @param {axios.RequestOptions} request - the raw {@linkcode https://github.com/mzabriskie/axios#response-schema Response} |
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.
I couldn't find axios.Response
and axios.RequestOptions
in axios/index.d.ts.
Also the callback signature doesn't seem to match how it is used here:
cb(null, response.data, response);
Shouldn't it be:
/**
* A function that receives the result of the API request.
* @callback Requestable.callback
* @param {Requestable.Error} error - the error returned by the API or `null`
* @param {any | boolean} result - the data returned by the API or `true` if the API returns `204 No Content`
* @param {axios.AxiosResponse} response - the raw {@linkcode https://github.com/mzabriskie/axios#response-schema Response}
*/
type callback = (
error: Requestable.Error,
result: (any | boolean), // https://github.com/mzabriskie/axios/blob/4976816808c4e81acad2393c429832afeaf9664d/index.d.ts#L48
response: axios.AxiosResponse // Not request but response
) => void;
Here is my standalone .d.ts file that works with webpack/ts-loader toolchain: |
Given the codebase has moved along quite a lot and there's a new version of The steps needed to generate a
This admittedly isn't the best TypeScript def; it has far too many To improve this in the future:
The remaining steps can probably be accomplished using codemods or somesuch. I don't know why tests are failing; am doubting it has anything to do with me given I don't touch the actual codebase in this PR. @akfish Would you mind taking a look at this again? I'd normally just add the excellent def you wrote to the repo and close this PR, but I feel some sort of automatic generation is necessary to keep everything up-to-date. |
Actually my typing was based on the automatic generation. So I can't take credit for that. :) I took a look at the typing. It would be easier if some automatic tests are included. Here's how I set it up based on DefinitelyTyped's method: I changed the {
"compilerOptions": {
"module": "commonjs",
"lib": [
"es6"
],
"noImplicitAny": true,
"noImplicitThis": true,
"strictNullChecks": false,
"baseUrl": "./",
"typeRoots": [
"./"
],
"types": [],
"noEmit": true,
"forceConsistentCasingInFileNames": true
},
"files": [
"github-api.d.ts",
"tests.ts"
]
} And added this line to {
// other lines
"types": "github-api.d.ts",
// other lines
} And added // Write tests here
// This file will be compiled by tsc to check typings
// It will not be executed
import GitHub = require('github-api')
let gh = new GitHub() Then you just run Now here're some issues I spotted:
|
@akfish It might be the Will take a closer look sometime tomorrow! Thanks for picking this up and adding some tests! |
No problem.
|
I just verified that the |
What's the status here? I'm interested in this enhancement. Could I take over if no one's working on it? |
@dvargas92495 Feel free! I don't expect I'll ever finish it tbth. |
As per #241 (comment) I've been working on a TypeScript definition.
The d.ts included in this PR is 95% automated, 5% by hand.
tsd-jsdoc
currently has a bug that moves types into class definitions, where they fail. They need to be in a namespace as per the file included herein.I'm leaving this as WIP for the moment so people can troubleshoot the issue with tsd-jsdoc; the goal is to have the d.ts file generated on every PR so it remains constant as the API all changes.