marijn/getdocs-ts
1
0
Fork 0
Code Issues Pull requests Releases Activity

Add support for substitution type and internal utility types #3

Closed
Saul-Mirone wants to merge 4 commits from main into main
pull from: main
merge into: marijn:main
Conversation 8 Commits 4 Files changed 5 +143 -3
Saul-Mirone commented 2022-11-12 13:30:04 +01:00 (Migrated from github.com)
Copy link

Closes: #2

Closes: #2
marijnh commented 2022-11-14 09:19:15 +01:00 (Migrated from github.com)
Copy link

typeParamSource is expected to hold a local item ID, so putting a path in there will make the doc generator emit nonsense.

Also, what kind of type gets the Substitution flag?

`typeParamSource` is expected to hold a local item ID, so putting a path in there will make the doc generator emit nonsense. Also, what kind of type gets the `Substitution` flag?
Saul-Mirone commented 2022-11-14 09:33:25 +01:00 (Migrated from github.com)
Copy link

The problem is that typescript will try to unwrap something like Omit and replace it with Pick implementation. I didn't find a good way to represent it.

I don't know the implementation details of Substitution flag, but if you run getdocs-ts with following code, it will create use that flag:

import { defineComponent } from vue;

export const a = defineComponent;

Maybe instead of throw errors, we can let users to pass in some options to handle the unknown types?

The problem is that typescript will try to unwrap something like `Omit` and replace it with `Pick` implementation. I didn't find a good way to represent it. I don't know the implementation details of `Substitution` flag, but if you run `getdocs-ts` with following code, it will create use that flag: ``` import { defineComponent } from vue; export const a = defineComponent; ``` Maybe instead of throw errors, we can let users to pass in some options to handle the unknown types?
marijnh commented 2022-11-14 09:53:25 +01:00 (Migrated from github.com)
Copy link

The representation of these kind of types seems pretty bizarre — no type with the name Omit appears anywhere. Instead the target property of the type holds Pick<T, K>, but those parameters aren't even defined there. The only place where TS seems to hold this information is the syntax parse tree, but reconstructing types from that in a general way would require us to write logic for every syntax node kind, which doesn't seem like a reasonable direction to go in.

I'll see if I can special case straightforward alias declarations where the type is simply a named type with parameters.

The representation of these kind of types seems pretty bizarre — no type with the name `Omit` appears anywhere. Instead the `target` property of the type holds `Pick<T, K>`, but those parameters aren't even defined there. The only place where TS seems to hold this information is the syntax parse tree, but reconstructing types from that in a general way would require us to write logic for every syntax node kind, which doesn't seem like a reasonable direction to go in. I'll see if I can special case straightforward alias declarations where the type is simply a named type with parameters.
Saul-Mirone commented 2022-11-14 10:33:27 +01:00 (Migrated from github.com)
Copy link

I agree. I think trying to construct the correct representation for complex types is not very useful. I'd rather keep the name of the type and add some comments on it.

The problem stop me using this package is that it will just throw errors for the type cannot be analyzed. It would be great if we can have some kind of common representation for this case.

I agree. I think trying to construct the correct representation for complex types is not very useful. I'd rather keep the name of the type and add some comments on it. The problem stop me using this package is that it will just throw errors for the type cannot be analyzed. It would be great if we can have some kind of common representation for this case.
marijnh commented 2022-11-14 10:34:45 +01:00 (Migrated from github.com)
Copy link

Patch 3911b490d4 adds a (disturbingly special-cased) solution for the Omit test case. b3d51a4055 adds support for template literals (including their arguments). Does that help?

Patch 3911b490d47f3f12083e5e35f812de59aa3a478f adds a (disturbingly special-cased) solution for the `Omit` test case. b3d51a4055be18d6520f5c9f703414408be20b7f adds support for template literals (including their arguments). Does that help?
Saul-Mirone commented 2022-11-14 10:52:37 +01:00 (Migrated from github.com)
Copy link

I'll test the package with defineComponent in vue to see if everything works fine.

I'll test the package with `defineComponent` in vue to see if everything works fine.
Saul-Mirone commented 2022-11-14 10:55:47 +01:00 (Migrated from github.com)
Copy link

👍 Works perfectly now.

👍 Works perfectly now.
Saul-Mirone commented 2022-11-14 10:57:21 +01:00 (Migrated from github.com)
Copy link

Closing since the solution is not good enough.

Closing since the solution is not good enough.

Pull request closed

Please reopen this pull request to perform a merge.
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
marijn/getdocs-ts!3
No description provided.