Reflection Support for Types and Other Constructs

[CoryGH]

Suggestion

The specific issue I'm running in to relates to reflection on TypeScript type constructs, specifically with:

export enum eNum {
    FOO = 0,
    BAR = 1
}
export type foo = {
    bar: string,
    baz?: number,
    qux?: eNum
};

I would like to be able to discern:

{
    name: "foo",
    members: [
        {
            key: "bar",
            optional: false,
            definition: "string"
        },
        {
            key: "baz",
            optional: true,
            definition: "number"
        },
        {
            key: "bar",
            optional: true,
            definition: "eNum"
        }
    ]
}

In a more general sense, TypeScript is sorely lacking in a lot of reflection functionality, to the point getting a similar result from an enum looks something like:

public static parseEnum(enumType: { [id: string]: number|string }): string {
    let skipNext = false;
    let dontSkipNext = false;
    let ret = '{\n\t';
    let entryCount = 0;
    for (let entry in enumType) {
        let hit = false;
        if ((!skipNext) || dontSkipNext) {
            if (isNaN(Number(entry))) {
                // @ts-ignore
                dontSkipNext = !isNaN(enumType[entry]);
                skipNext = true;
                hit = true;
            } else {
                skipNext = false;
            }
        } else {
            skipNext = false;
            dontSkipNext = false;
        }
        if (hit) {
            if (entryCount > 0) {
                ret += ',\n\t';
            }
            ret += entry.toString() + ' = ';
            if (typeof enumType[entry] === "string") {
                ret += '"' + enumType[entry].toString() + '"';
            } else {
                ret += enumType[entry].toString();
            }
            entryCount++;
        }
    }
    ret += '\n}';
    return ret;
}

It would be nice if TypeScript supported reflection with 100% coverage to the point of .NET without all the hacks to work around it and the duplicate-code/boilerplate required when reflection simply isn't possible, such as in the case of type constructs.

🔍 Search Terms

Reflection, Types

✅ 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 feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

.NET-tier reflection.

📃 Motivating Example

See above.

💻 Use Cases

See above.

[MartinJohns]

Duplicate of #3628.

---

[x] This feature would agree with the rest of TypeScript's Design Goals.

It does not agree with the TypeScript Design Goals. See non-goal 5, which mentions this explicitly.

Add or rely on run-time type information in programs, or emit different code based on the results of the type system. Instead, encourage programming patterns that do not require run-time metadata.

[CoryGH]

Add or rely on run-time type information in programs, or emit different code based on the results of the type system. Instead, encourage programming patterns that do not require run-time metadata.

With all due respect, that's not a wise philosophy. Restricting developers in what they can do is antithetical to JavaScript in general, but in this specific case is a true absurdity because reflection of types is a basic requirement to creating libraries which extend functionality and reduce boilerplate, which both JavaScript and TypeScript suffer from immensely.

[RyanCavanaugh]

Non-support of reflection is an intentional design goal; you're free to disagree with that but we've found it to work well so far.

[CoryGH]

@RyanCavanaugh What possible goal does intentional non-support of reflection have other than to harm the utility of the language?

[RyanCavanaugh]

Great question; not making the types of your program part of your runtime contract means we can do semantics-preserving type representation changes between releases (such as going from T & (A | B) to (T & A) | (T & B), which we did in the past) without fear of breaking the runtime behavior of your program. The ability to make those kinds of changes has been a necessary component of virtually all the innovation in the type system over the years.

[CoryGH]

Ah, so is this something where reflection is being saved for when TypeScript is more mature as a language and in turn would have less changes required for it?

[RyanCavanaugh]

I don't think we'll ever stop innovating in the type system; it's where the value is. The future is far away and if things change we will of course re-evaluate. Meanwhile, projects like io-ts are doing a great job of providing ways to write the metadata in value space and generate types from that, which has proved to be a great approach.