Type introspection at runtime

[strogonoff]

This is more of a question so feel free to close. Is it possible to introspect at runtime the properties of a type instantiated with type()?

[strogonoff]

To provide at least partial answer to myself: the definition property (typed as unknown) on the object reveals the definition used when creating the type. The definition is not normalized or canonicalized e.g. for insignificant whitespaces and such, and doesn’t provide structured data about involved types: e.g., it can tell us that a field was defined as "contributor[]", but I don’t yet see how to programmatically determine that it is a list of contributor instances, resolve the contributor type to see what kind of properties it allows, etc. There must be a function that does this kind of parsing somewhere, I suppose…

[ssalbdivad]

You're looking for the .node prop!

Each type is internally represented using objects like this:

const myType = type("number%2 | string<10")
// { number: {divisor: 2}, string:  { limit: 10, comparator: "<" } }
console.log(myType.node)

Internally, these nodes represent a full type system that can determine assignability between any two types, with utilities for doing things like extracting props.

You can even create types directly from these node structures using a tuple expression with full static-inference!

        const t = type([
            "node",
            {
                object: {
                    class: Array,
                    props: {
                        "[index]": { object: { props: { name: "string" } } }
                    }
                }
            }
        ])
        
        type T = typeof t.infer
        //      ^? { name: string }[]

Feel free to take a look at these tests for some more examples of various types and their node representations.

We plan to expose and document those APIs in the near future, but in the short-term these representations should be relatively intuitive, so feel free to poke around and extract what you need.

[strogonoff]

This is spot on!

• Upon some experimentation (which I could have avoided if I just looked at the tests) I found that there is a difference in structure between optional and non-optional properties, which is slightly confusing (when introspecting types, I’d have to test whether it’s a list and its first element is a string with question mark)—but maybe there was a reason for that
• sometype.node is typed as unknown… If I had time to contribute proper typing to this property, where would I start?

[ssalbdivad]

So the structure is optimized to be:

• Concise
• Easy to read/write
• Directly serializable
• Efficient to operate on

The reason that optional keys are represented this way as opposed to e.g. splitting up props into optionalProps and requiredProps is so that when intersecting props, the keys of the object can be directly treated as a set and not cross-referenced across multiple categories. Some aspects of this internal representation may change, but the changes aren't likely to be significant as the current structure was the result of a significant amount of iteration, and I've got lots of other features to build 😊

Although definition can for the most part only be meaningfully typed as unknown, Node should have a very rich type representation. I think the problem may be that you need to discriminate the type at various levels, e.g. the root can either be a string representing a reference to another alias, a config node, or a record of domains (type categories) to branches that are valid within that domain.

As part of the perf-optimization work I'm doing now, I'm considering adding a wrapper to these nodes that would likely make them much more intuitive to interact with, but for now, you should be able to work your way through the type structure starting here.

That said, if you're interested in contributing, I'd love to help however possible! You can check out our guide here and our backlog here. Unfortunately, there are basically no details as it's mostly notes for me, but I'd be happy to add them if an issue catches your eye but you're unsure how to proceed!

I'd also love to hear about what you're planning on doing with the types at runtime- I have lots of ideas for that, and some of them may eventually have a home in the core package!