-
-
Notifications
You must be signed in to change notification settings - Fork 17
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
Update docs for newcomers #6
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is a good idea. Adding information about how directives fit into the unified "flow" will help people figure out how to do what they want.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Even better than 98a3ce5 for orienting a new user.
This comment has been minimized.
This comment has been minimized.
@nemo-omen I’ve significantly reworked the docs some more. The rendered view is here: https://github.com/remarkjs/remark-directive/blob/docs/readme.md. The plan is to apply similar changes to all projects. |
// This plugin is an example to let users write HTML with directives. | ||
// It’s informative but rather useless. | ||
// See below for others examples. | ||
/** @type {import('unified').Plugin<[], import('mdast').Root>} */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure it JSDoc based type annotations should be used in examples. It's not wrong, but IMO it adds a bit of visual noise and doesn't really help to clarify the example.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe. It doesn’t hurt JS users who copy/paste (maybe a bit, as you mention, if it’s noisy).
It does boost the idea to both JS and TS users that types can come in plain JavaScript.
And it might signal to TS users how things can be typed, as they sometimes have a hard time typing unified plugins/utilities (using a lot of any
s or unist.Node
)?
But it’s less noisy than both JS and TS code blocks but is still copy/pastable compared to just TS code blocks.
.use(myRemarkPlugin) | ||
.use(remarkRehype) | ||
.use(rehypeFormat) | ||
.use(rehypeStringify) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sometimes the order of plugins matters (transformers) and sometimes it doesn't (syntax extensions / custom parsers / compilers). I don't think it's necessary to document here, but it might be good to document for plugins that do depend on output of other plugins.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it ever weird though? As in, do people come in thinking the order doesn’t matter?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not really. If anything it can be a bit surprising things work regardless of order, not the other way around.
Initial checklist
Description of changes
This improves the docs, focussing on newcomers.
The goal is to make it easier for folks without background information on unified/remark/asts/etc to figure out what a project is and if they need it or something else.
I thought I’d kick something off but the plan is for similar changes to go out to all unified readmes.
Related-to: unifiedjs/unified#168.
/cc @nemo-omen