Parse quoted names in qualified names

[weswigham]

As I alluded to in #40679, the real root cause of #40152 is that we can't even reference the type-side of the non-identifier enum members via a type reference, because the reference syntax has no allowances for non-identifier names. This PR allows the type-side of non-identifier exports to be referenced within the type system via references of the form NS."string name". Meaning you can now have code like this:

// @filename: export.js
exports["a thing"] = class {
    a;
    b;
}
// @filename: usage.ts
import * as ns from "./export";

export const instance: ns."a thing" = new ns["a thing"]();

Or like this:

// @filename: a.ts
export enum Foo {
    "1-1",
    "1-2"
}
// @filename: b.ts
import {Foo} from "./a";

export type FooFirst = Foo."1-1";

If we want to take this (and I think we do, between current enum and js exports and upcoming wasm exports), we probably want to do it after master has swapped to 4.2, since the 4.1 beta has been cut - so there's not much time pressure to look into this yet - I just wanted to have this ready and available for consideration and discussion. We may also want to pair it with additional syntax on the declaration side to allow the declaration of non-identifier export names in ambient contexts (eg, export const "a thing": Type;) - so js files (and upcoming wasm files) can be better represented with a declaration file.

[andrewbranch]

@typescript-bot pack this

[typescript-bot]

Heya @andrewbranch, I've started to run the tarball bundle task on this PR at 7ba8bbf. You can monitor the build here.

[andrewbranch]

Haven’t gone over the declaration emitter changes in much detail, but have a couple questions to start with

[andrewbranch]

It seems like a lot of these shouldn’t have gone away?

[weswigham]

I made the error on .<T> outside jsdoc into a parse error to simplify the types, which has the side effect of silencing these grammar errors until it's fixed (grammar errors issued in the checker are only issued when the containing file has no parse errors).

[andrewbranch]

Can a string entity name have type arguments?

// @Filename: thing.js
/** @template T */
class Thing {
  /** @param {T} x */
  foo(x) {}
}
exports["a thing"] = Thing;

// @Filename: index.ts
type Thing<T> = import('./thing')."a thing"<T>

?

[weswigham]

Sort-of yes - those type arguments are attached to the import type (or type reference) itself, though. The type arguments sometimes attached to identifiers are provided for the language service in some cases to provide detailed instantiation information for qualified names (like when we return strings like NS.Cls<T>.B) - currently a StringLiteralLike doesn't support appending those, so I'm just omitting them, rather than complicate the types. To be honest, I'd prefer to move them into the QualifiedName structure instead of having them on Identifier (and now potentially string literals) if we wanted to uniformly keep the behavior.

[andrewbranch]

If the only kind of EntityName that can start with a StringLiteralLike is the qualifier on an ImportTypeNode, would it make more sense to make that a special case and leave the meaning of EntityName unchanged?

[weswigham]

Maybe; but when going in that direction, the suite of utility functions that needed to handle it was less clear. It could be worth the change, regardless.

[sandersn]

Unfortunately, we never finished reviewing this PR. It is pretty old now, so I'm going to close it to reduce the number of open PRs.