Declaration merging lib file's `unique symbol` with `symbol` errors

[LukeAbby]

This snippet succeeds on Strada:

interface SymbolConstructor {
    readonly toStringTag: symbol;
}

But fails on Corsa. This effects packages like @types/jquery which does this to polyfill lib.es2015.symbol.wellknown.d.ts.

Is this another intentional change à la #1192 or is this a so far unimplemented feature?

[Andarist]

This looks like an intended break. This works in Strada thanks to (code):

// TODO: If back compat with pre-3.0/4.0 libs isn't required, remove the following SymbolConstructor special case transforming `symbol` into `unique symbol`
if (type.flags & TypeFlags.ESSymbol && isGlobalSymbolConstructor(declaration.parent)) {
  type = getESSymbolLikeTypeForNode(declaration);
}

[LukeAbby]

I discussed this a fair bit on Discord with @jakebailey and @Renegade334.

To investigate breakage, @Renegade334 put up a PR and @jakebailey ran top400 on it. It looks like this causes a breakage in 1 package in the top 400, being pmndrs/jotai. I investigated further and it looks like it broke because both ReactiveX/rxjs and 0no-co/wonka polyfill Symbol.observable with a symbol and this ultimately ends up desyncing Observable (symbol) and ObservableLike (unique symbol).

Switching to unique symbol for the two polyfills and changing symbol to typeof Symbol.observable in one place in rxjs fixes this issue so it's not too hard to fix, though it does involve touching two packages and then getting rxjs to update its dependencies. Though I wasn't directly getting errors about the "subsequent property declarations" like I was when testing @types/jquery which was a bit odd.

Finally @Renegade334 put together this query looking for usages of interface SymbolConstructor and found 462 unique repos (non-forks) that appear to use this pattern. unique symbol's support was added in TypeScript 2.7, over 7 years ago, so I doubt very many libraries are intentionally limiting themselves to using symbol in order to avoid breakage but instead copying from other packages. If TypeScript had a mechanism for warning the user or only erroring in your own code I would be eager to suggest such a thing but as it stands it seems like it could potentially have far reaching consequences.

[Renegade334]

Removing this bit of history feels like a less invasive change than other lib-facing behaviour changes being considered, eg. #300.

It seems like the affected cases fall into two main categories: high-profile libraries polyfilling Symbol.observer (which should have no problem pushing a one-line change), and mothballed old projects that are unlikely to gel with TS7 out-of-the-box anyway.

[jakebailey]

I feel somewhat confident that the number of libraries this issue affects is higher than the number of correct uses of the cursed and misnamed no-default-libs feature 😅