Idea: Can declaration emit synthesize type aliases?

[amcasey]

Object types can be very large and in (e.g.) a react project that makes heavy use of type inference, it's not uncommon to have to refer to a type that is either not imported or is simply anonymous (e.g. a props type). When these appear in multiple places in a declaration file, they tend to expand it considerably. Perhaps we could just synthesize type aliases for them?

• We'd have to be careful not to change the exported API shape
• We could use a heuristic to skip the work for small types (e.g. < 20 characters)
• Even if we didn't wait until the second use of a type to decide to extract it, we'd be adding ~4 tokens per type (type id = and id at the use site)

[amcasey]

With #44044, this is part of a larger discussion of how we could reduce the size of declaration files to make them faster to read and write (ideally, without sacrificing readability).

[weswigham]

#30979 is along the lines of what I think we'd prefer to see

[amcasey]

@weswigham What's the scope of those inline type aliases? Being able to use them across multiple declarations seems key to reducing declaration file size.

[weswigham]

In that case, within a given type node, so you can serialize a recursive or self-referential type. (Which today usually expand till they hit a depth limiter)

[jleider]

Reviving this idea.

I am discovering we're having similar issues specifically with the io-ts library (similar to zod which I believe has the same issues) where the type derived from the codec expands everywhere its referenced instead of using a simpler named type. Some of our emitted definition files are tens of MB with repetitive type expansion. Using explicit types reduces the files back to expected sizes but defeats the purpose of being able to infer the types.