Improve TsInfo support

[cristatus]

Now expands type aliases and interfaces with literal only types. Also allows to expand inherited props.

Example:

<TsInfo src='./Button.tsx' name='ButtonProps'` />
<TsInfo src='./Button.tsx' name='ButtonProps:*'` />
<TsInfo src='./Button.tsx' name='ButtonProps:AsProp'` />
<TsInfo src='./Button.tsx' name='ButtonProps:AsProp:BaseProps'` />

Fixes #33

[csr632]

Thanks for your contribution！I will look into this in this week.

There is some design detail I want to discuss: does this feature mean we need to support 'pulling' tsInfo from multiple files? Things will get very complicated(and slow) when it involve multiple files & project tsconfig & ts error.

I want to avoid analyzing the whole ts project for a single tsInfo request.

I think we should design some rules and restrictions to users. So that is feature can be simple and powerful.

[cristatus]

There is some design detail I want to discuss: does this feature mean we need to support 'pulling' tsInfo from multiple files? Things will get very complicated(and slow) when it involve multiple files & project tsconfig & ts error.

I want to avoid analyzing the whole ts project for a single tsInfo request.

No, only the given file but typescript compiler is already pulling other modules to resolve the imported types.

I think we should design some rules and restrictions to users. So that is feature can be simple and powerful.

Yes, I suggest following restrictions:

1. expand types with literal type properties only
2. consider property of non-literal type if the type itself confirms 1st rule
3. also expand types with method properties but confirming 1st and 2nd rule for remaining properties

BTW, the MR has few issues. I am working on a better implementation.

[csr632]

No, only the given file but typescript compiler is already pulling other modules to resolve the imported types.

I want to encourage users to extract the types that they want to document into a seperate file tree (a minimal sub-project) that can be analyzed efficiently. Here is an example file structure:

src/
  index.ts
  README.md

  types/
    ButtonProps.ts
    Size.ts
    ButtonVariant.ts

So that we can analyzed tsInfo from the types/ folder only, without pulling in src/index.ts. If it use types imported from outside like import type {ButtonProps as AntButtonProps} from "antd", we should ignore it and don't expand it.

To enforce this restriction, we should ensure only the explicit-granted files will be analyzed. We can pull in the files within the given directory by default. If users want to pull in another file, need to write a comment explicitly in the entry file to instruct this loader. A tool that we can consider: typescript-vfs.

For even better performance, we can consider reusing same ts program between multiple tsInfo requests. For example:

<TsInfo root="./types" name="ButtonProps" />
<TsInfo root="./types" name="Size" />

These two requests can use the same ts program (with entry point being types/index.ts). Just an idea to explore, you don't need to support this. (I am not sure how to invalidate cache after files are updated.)

Yes, I suggest following restrictions: ...

That would be a great default behavor. I also suggest supporting comment directives like @tsInfoExpand or @tsInfoNoExpand to fine-tune it.

[csr632]

By the way, If you encounter problems like "virtule modules not supporting hmr", don't worry about it. I am planning a new fs-watching machanism to support hmr of all virtule modules (not only virtual page modules).

[cristatus]

Thanks for the updates. It's a really good project for documenting components. We have just started developing ui components so took a chance to use vite and vite-pages and the experience so far is really good.

I would also love to see docz like Playground and Props to support live playground and PropTypes based properties listing.