-
-
Notifications
You must be signed in to change notification settings - Fork 353
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
typings: visitor typings for remark-stringify #426
Comments
This is a continuation of #383 (comment) Some previously discussed solutions One option would be a generic. interface Transformer<I extends Node = Node, O extends Node = Node> {
(
node: I,
file: VFileCompatible,
next?: (error: Error | null, tree: O, file: VFile) => {}
): Error | O | Promise<O>
} Which would guarantee that the input and the output are a super type of a unist Another would be to add a generic to Processor, and set that generic to a union of all types for the give language. type AllUnifiedTypes = Node | Parent
const unifiedProcessor = unified<Settings, AllUnifiedTypes>
type AllRemarkTypes = List | ListItem | Table | ...
const remarkProcessor = unified<Settings, AllRemarkTypes> But then there would be the question of how do plugins participate in the supported node typings? |
Related to unifiedjs/unified#53. Related to unifiedjs/unified#54. Related to unifiedjs/unified#56. Related to unifiedjs/unified#57. Related to unifiedjs/unified#58. Related to unifiedjs/unified#59. Related to unifiedjs/unified#60. Related to unifiedjs/unified#61. Related to unifiedjs/unified#62. Related to unifiedjs/unified#63. Related to unifiedjs/unified#64. Related to #426. Reviewed-by: Titus Wormer <tituswormer@gmail.com> Reviewed-by: Junyoung Choi <fluke8259@gmail.com> Reviewed-by: Christian Murphy <christian.murphy.42@gmail.com> Co-authored-by: Junyoung Choi <fluke8259@gmail.com> Co-authored-by: Christian Murphy <christian.murphy.42@gmail.com>
@ChristianMurphy Is this actionable, and useful enough? |
Actionable, yes. |
We don’t have visitors anymore, so I’ll close this. Type changes can be done to |
Subject of the feature
Give
visitor
s a type safe way to depend on super types of unistnode
Problem
In this example
to get a
HeadingNode
from the visitor it needs to be castas (Node & {depth: number})
.Which reduces the type safety since any property can be added in the
{}
block and typescript will accept it.Expected behaviour
header
should automatically of typeHeaderNode
This should be safe, because the visitors are staticly defined ahead of time.
remark/packages/remark-stringify/lib/compiler.js
Lines 37 to 63 in acada43
The text was updated successfully, but these errors were encountered: