Skip to content

types: create jsdoc based typescript typings #2

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

Merged
merged 21 commits into from
Feb 11, 2021

Conversation

ChristianMurphy
Copy link
Collaborator

No description provided.

@ChristianMurphy ChristianMurphy marked this pull request as ready for review February 10, 2021 04:26
Comment on lines +11 to +14
* @property {*} [Fragment]
* @property {*} [jsxs]
* @property {*} [recastPlugins]
* @property {*} [useMDXComponents]
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

more definition around what these could/should be could be helpfup

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess there are no types for Fragment, jsx (which is missing here), and jsxs https://github.com/DefinitelyTyped/DefinitelyTyped/blob/a05cc538a42243c632f054e42eab483ebf1560ab/types/react/index.d.ts, perhaps because they are normally injected instead of supposed to be imported

Comment on lines +11 to +14
* @property {*} [Fragment]
* @property {*} [jsxs]
* @property {*} [recastPlugins]
* @property {*} [useMDXComponents]
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess there are no types for Fragment, jsx (which is missing here), and jsxs https://github.com/DefinitelyTyped/DefinitelyTyped/blob/a05cc538a42243c632f054e42eab483ebf1560ab/types/react/index.d.ts, perhaps because they are normally injected instead of supposed to be imported

lib/evaluate.js Outdated
*
* @typedef {ProcessorOptions & RunnerOptions} ProcessorAndRunnerOptions
* @typedef {{ [name: string]: any }} ComponentMap
* @typedef {{ [props: string]: any, components?: ComponentMap }} XDMProps
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe MDXContentProps instead? To me that explains more that they’re for the content component

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe MDXContent can also be defined as a function, which always returns a call to jsx / jsxs / pragma

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

applied the first, can you expand what you mean by the second?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The result of evaluate() at .default is a component: a function that takes MDXContentProps and returns a call to jsx: in React, I’m sure there’s a type for that.

Now, assuming jsx had types in React, then there’d be a type for its return value, right? Then I’m guessing that you could take that value and define it as .defaults return value too?

Illustrated in another way: jsx is a function: f() = x. So the return value of .default is also always x

(and for my comment I forgot that pragma is not an option for evaluate, and the return value of jsxs and jsx are the same)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The result of evaluate() at .default is a component: a function that takes MDXContentProps

Right, and that is the ExportMap type on line 19

Now, assuming jsx had types in React, then there’d be a type for its return value, right?

For react yes,
one that is consistent across React, Preact, and Vue, I'm not so sure.
I think there are differences (it would take some experimentation to check), and if there are differences, it would be difficult to capture even with conditional types watching what was passed to pragma.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There would be difference but the result of that f() = x should be accessible though?

If someone does evaluateSync({jsx: f}).default() the output type is still x, and jsx is a required option.

I understand that all the things passed as jsx will be different, but they’re required to be functions, so that might help?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@wooorm
Copy link
Owner

wooorm commented Feb 10, 2021

One extra thing is that TS is probably not reading webpack.cjs in the root, due to its extension? That might be useful for webpack folks wanting types

@ChristianMurphy
Copy link
Collaborator Author

I can add jsdocs to webpack.cjs, but the extension will conflict with

error TS6054: File 'xdm/webpack.cjs' has an unsupported extension. The only supported extensions are '.ts', '.tsx', '.d.ts', '.js', '.jsx'.

adding cjs extension support in typescript is an open item at microsoft/TypeScript#38784

@wooorm wooorm merged commit 8a6e19a into wooorm:main Feb 11, 2021
@wooorm
Copy link
Owner

wooorm commented Feb 11, 2021

find . -maxdepth 3 -type f -name "*.d.ts" was removing a ton of stuff from node_modules btw, which was hiding https://github.com/wooorm/xdm/runs/1878119750?check_suite_focus=true#step:5:157

@ChristianMurphy ChristianMurphy deleted the types/add-jsdoc-based-typings branch February 11, 2021 17:23
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

Successfully merging this pull request may close these issues.

2 participants