Skip to content
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

Add more information on return type of methods #106

Open
jpike88 opened this issue Sep 25, 2018 · 6 comments
Open

Add more information on return type of methods #106

jpike88 opened this issue Sep 25, 2018 · 6 comments

Comments

@jpike88
Copy link

jpike88 commented Sep 25, 2018

FunctionDeclaration {
  name: 'getNotificationSettingsForUser',
  isExported: false,
  type: 'Promise<{\n    notificationRows: any;\n}>',
  start: 5886,
  end: 6006,
  parameters:
   [ ParameterDeclaration { name: 'this', type: 'ApiHandler', start: 5934, end: 5950 },
     ParameterDeclaration { name: 'userID', type: 'any', start: 5952, end: 5963 } ],
  variables: [] }

The type variable is all string, how can we improve analysis to get at its structure?

@fennecbutt
Copy link

I was just about to create an issue for this as well. It'd be great to have the return types parsed like everything else is, rather than just a string.

@jpike88
Copy link
Author

jpike88 commented Oct 12, 2018

Try my fork out, let me know if you improve it further and submit PRs to it. I have it on npm as typescript-parser-deluxe. This repo is too sluggish to rely on

@fennecbutt
Copy link

fennecbutt commented Oct 16, 2018

Did you mean that your fork provides the return type structure? Or that I should get it in there & PR?

I tried typescript-parser-deluxe and the return type is still provided as:
"type": "{\n a: number;\n b: number;\n }",

I'll see what I can do about getting it to provide it in a structured way. I have a feeling that the reason that it provides the return type as a string like that is because the referenced types are unknown. I'm going to try parsing the node/es6 declarations as well as my own and see if that helps the parser fill in the blanks...

Edit: after testing with a simplified return type (an object with static proprties set to constant values) it still provides the return type as a string. I'll look into the changes required to get the return type provided as a structure rather than a string.

Cheers for your help @jpike88

@jpike88
Copy link
Author

jpike88 commented Oct 17, 2018

Both! I will ensure the library is kept up to date. You'll notice a typeArguments property on some nodes, that's me exposing types via an alternate means. I didn't want to introduce breaking changes to the library

@mundusnine
Copy link

mundusnine commented Oct 24, 2018

@jpike88 Would the pull request #101 be something that would be desirable in your typescript-parser-deluxe ? The most important commit was the first one which is called: 'Added better js types'

What it does basically is add better type detection more so for JS then TS. If so I will work on merging it into it.

@jpike88
Copy link
Author

jpike88 commented Oct 25, 2018

Yep go for it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants