Stabilize error code, have an error listing, and for each error code have a webpage that explains it

[octref]

Linters such as ESLint have a webpage for each error code:

For example, no-console

TypeScript gives back mystic codes:

that leads to a bunch of SO answers and blog posts:

In VS Code, we added the ability to have links for diagnostics: microsoft/vscode#11847

I request TS to stabilize error codes, provide a webpage listing of all errors, and one webpage for each error code to explain it. TS errors in editor can then be linked to the official docs.

[weswigham]

We've talked about this in the past - We don't want to stabilize the TSXXXX error codes - that they're "public" is an artifact of needing a stable identifier to refer to a specific diagnostic with for quickfixes and such. We freely change the code used to refer to a given error from release to release as we improve, change, or specialize message text. What we want is short, human readable names for every error, like no-implicit-any or parameter-assignability-failure (like eslint) which may be shared between individual messages, but logically group them by topic, which is then a stable way to refer to that "kind" of error (this would be hugely useful for quickfixes, which today enumerate all the codes they respond to in a hugely verbose way). What we don't have is anyone who's been able to commit to going through our big ol' diagnosticMessages.json and assigning each message a meaningful short name.

[octref]

I agree readable short names would be better error code for the public consumption. Anyway, I do think this would help with people experience fixing errors in their TS code.

[orta]

Aye, there's about 1,200 compiler messages to go through.

I've ran a few bug bashes before, I wonder if it's feasible for us to do a one-off community event over a weekend in trying to handle it.

Could try to generate (or find the compiler tests) a reproduction for each compiler flag (I get this can be very complex for some, but the majority should be doable) as well as a short code which could be used to seed these kind of docs.

[DanielRosenwasser]

I think human-readable codes are (maybe) useful for suppression, but it's not clear to me what value a webpage explainer for a majority of these gives.

For example, let's look at a few error messages at the beginning of diagnosticMessages.json:

• An index signature cannot have a rest parameter.

• An index signature parameter cannot have an accessibility modifier.

• An index signature parameter cannot have a question mark.

Are we supposed to have a webpage with each of these explained? Is the explanation for each of these just the rationale of a design decision?

Maybe instead we only document a subset of error messages. If so, which? And if it's only a few, does it make sense to have an entire section of the website dedicated to this? I really need to understand what the use-case is because this gets brought up a lot, but I don't know why we would do this instead of making the error messages better in specific cases.

[octref]

You can try asking 10 new JS users who have never used TS what those 3 messages would mean to them, and how they would handle that error.
Knowing that you can fix all errors because there would be a page that explains it is a huge confidence booster for adoption. Vue has a shining example: https://github.com/vuejs/vue-migration-helper

[typescript-bot]

Hello! As per #2804, we are automatically closing all open issues. Please see #2804 for a description of what issues and PRs can be accepted going forward.