-
-
Notifications
You must be signed in to change notification settings - Fork 464
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
Add rustdoc comments to all public APIs #5870
Comments
Just to add, documentation on internal APIs is also helpful - not just for new contributors, but also for the core team. I often find myself a bit lost in areas of codebase I've not been in for a while. Obviously, public API is higher priority, though. |
I'm not familiar enough with the transformer to tackle this. Is someone else willing to handle it? |
I am currently working through the transformer fixing bugs and refactoring. I'll do my best to also add comments as I go. FYI we've adopted a "style guide" for writing transforms which includes requirement to comment well. |
I'm also not super familiar with codegen or ID, would love support on these |
- towards #5870 Adds some very basic docs for methods and properties related to `LintContext` and `ContextHost`.
- towards #5870 Adds some very basic docs for methods and properties related to `LintContext` and `ContextHost`.
- towards #5870 Adds some very basic docs for methods and properties related to `LintContext` and `ContextHost`.
It seems like we can add |
Close as stale for house keeping. Nobody likes writing documentations so I don't think we'll get any help 😅 |
Moving to backlog, as I think this is something that we should tackle at some point - I believe it is important, for the reasons that Don gives at the top. |
Transferring to backlog repo did not work. Github seems to have some kind of race condition. Going to leave this for a few hours for it to settle down and then try again. |
Transferred to oxc-project/backlog#130 |
Good documentation is a critical part of promoting adoption from other projects. If users cannot understand how to use our tools, odds are they wont. We should document as much of our public API as possible. At the very least, all mostly-stable APIs should have examples and descriptions on how to use them.
We have a lot of great examples, but many options and return structures are missing descriptions. Plenty of business logic is also missing descriptions.
Crates
These are, in my opinion, the crates that are most important to document right now
oxc_diagnostics
#5865Basically, if it's used anywhere from reading a file -> parsing -> transforming -> printing, then it is a high-priority candidate.
The text was updated successfully, but these errors were encountered: