-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Document behavior, gotchas, etc, for public TypeChecker API #53239
Comments
This also came up during the ESLint/TS meeting a few weeks ago. |
This is pretty vague - unless you have something in mind that you're already prepping a PR for. Otherwise, can we list 10 functions/methods that would be a good starting point? |
I don't think I'm experienced enough to write the final versions; this is mainly so we don't forget about what we talked about in the meeting. From the linked thread above, a start would be:
@bradzacher also mentioned instantiated types, but, I don't see that in our public API. I can't recall if there were specific requests otherwise. |
Of course the best would be to require JSDoc comments on any and all TypeChecker APIs, but that seems like a lot for a first pass. |
My feedback from the developer of the build system using the public API TS. The lack of full-fledged API documentation has raised the threshold for entering the development of extensions for the compiler, as a result, there are few specialists and they have very good salaries, thank you for this, without irony. The only relevant documentation is |
A common (valid) complaint about our public API is that we don't have any documentation for what the methods do, why to use them, why not to use them, the gotchas, etc.
In more recent API PRs (like #52467 and #52473), we've added descriptions, but we should do the same for the existing methods if possible.
The text was updated successfully, but these errors were encountered: