Add more context to unique symbols that appear in type errors

🔍 Search Terms

unique symbol type error
I went through every bug i could find to see if someone suggested anything like this - no luck.

✅ Viability Checklist

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

Aa part of tracking down https://github.com/sveltejs/svelte/issues/15182 and https://github.com/sveltejs/svelte/issues/13760, you can see the error messages from the typescript compiler around conflicting unique symbols correctly state that the types are different. But they give you no real context about where the unique symbols are from, or even give the unique symbols different numbers.

So you get something like (ignore the annoying string that svelte has added to the type):

And if you are a normal developer, you are just like "uh, okay" - the types look identical because by name, they are! (Both the different unique symbols are named SnippetReturn).

The actual part that matters is really that part that states that the unique symbol is not assignable to unique symbol. At the very bottom.

But the really important part, that you can't tell here, is that the unique symbol it's talking about in "& unique symbol" and the one in 'type "unique symbol"' are different unique symbols.

This was hard enough to tell that nobody actually understood what this means., and just assumed it was breakage elsehwere.

All of this is coming from the typescript compiler/parser, and you can see this with the repro in 15182 that is just a bare ts file. Running tsc on the project will give you a similar message. tsc happens to name the overall containing types at the top, which is nice. But this only looks nice because of the import paths. In the real errors, you either don't get the import statements, or you see Type 'import("svelte").Snippet<[]>' is not assignable to type 'import("svelte").Snippet<[]> at the top which helps make you think the tooling is broken, not the code.

It would be really nice if, for unique symbols (which are all unique), it gave you more context.

Like Type '{ '{@render ...} must be called with a Snippet': "import type { Snippet } from 'svelte'"; } & (unique symbol declared at line 57 of file bar.ts)' is not assignable to type '(unique symbol declared at like 48 of file foo.ts)'

So it's totally obvious they are not the same unique symbol.
Maybe even add "Different instances of unique symbols are never compatible" at the end to help.

If this is too hard, even just something like:
Type '{ '{@render ...} must be called with a Snippet': "import type { Snippet } from 'svelte'"; } & (unique symbol #1)' is not assignable to type '(unique symbol #2)'. #1 and #2 are two different instances of unique symbols, and different instances of unique symbols are never compatible

So that it was similarly obvious, though not quite as helpful.

Another option would be to point out the SnippetReturn's it's talking about are not the same (SnippetReturn is the thing that is typeof <unique symbol>)

Type '{ '{@render ...} must be called with a Snippet': "import type { Snippet } from 'svelte'"; } & typeof SnippetReturn (SnippetReturn is an instance of a unique symbol) ' is not assignable to type '{ '{@render ...} must be called with a Snippet': "import type { Snippet } from 'svelte'"; } & typeof SnippetReturn (SnippetReturn is a *different* instance of a unique symbol)'. Two different types with this name exist, but they are unrelated.

This is even less helpful, but still IMHO an improvement.

📃 Motivating Example

Tracking down a svelte bug - https://github.com/sveltejs/svelte/issues/15182
This bug went unnoticed despite a number of reports in part because the error message didn't clearly help understand what was broken, and so folks wrote it off. it was worsened by the fact that the typeof's of the different unique symbols had the same name, making the error message look like a bug or weird failure.

Had it contained the filenames and declarations, someone would probably have looked and it would have been instantly obvious that it not was random weirdness, but a real bug.

💻 Use Cases

1. What do you want to use this for?

Better error messages

2. What shortcomings exist with current approaches?

The current error message is missing enough that there are concrete cases of very smart developers missing the real bug.

3. What workarounds are you using in the meantime?

Using people like me with lots of compiler experience who are willing to jump very far down crazy compiler and language server rabbit holes when bugs look weird.

Start by reproducing the conflict in a bare .ts file from the linked Svelte examples and running tsc. Inspect the TypeScript compiler/parser handling of unique-symbol type errors; done means diagnostics distinguish the incompatible unique symbols with useful declaration, file, or instance context.