Query Type Information from within TypeScript

I'm wondering if there's currently any supported way to query the type information about user-generated interfaces/classes/etc from within TypeScript itself.

It looks like the "services" code in the TypeScript distribution provides some of this, but it's mostly geared for providing tooling. I'm more interested in "reflection-like" capabilities, although it doesn't really need to be reflection
in the sense of runtime type information, and I'm aware that the language team doesn't want to add anything that would degrade the resulting JS files (like "proper/runtime" reflection). Compile/build type support would be sufficient.

Maybe something analogous to the compiler emitting a declarations (.d.ts)-like file that generated real JS objects that could be used within JS/TypeScript? I'm sure I could write a parser/preprocessor step for this myself, but I don't want to reinvent anything
if it's already available, etc.

I'm not sure I'm following what exactly you want. Can you describe what you're trying to accomplish that isn't traditional JavaScript style reflection or akin to the language service/compiler APIs asking for type information?

You're right in that I'm asking about capabilities that are akin to the language services, specifically retrieving the type hints for a specified class/interface, etc.

I browsed through the "Services" code, and from what I can tell it's really geared towards tooling (eg, it seems to have a heavy emphasis on querying given a POSITION in a file instead of a specific TYPE name). What I would like is the ability to
query by class/interface/type name instead. I think I could achieve what I want by have some build-time step to translate the generated *.d.ts files to .js files containing JSON representations for them. I just wanted to make sure that there isn't a more "supported"
or "acceptable" solution.

Yes, the examples that prohazko gave illustrate my original request very well, and would add basically no overhead to the generated JS (something that I know is a design goal). It keeps all of the new functionality strictly as build-time compiler steps
and the code gets stripped away to the bare CONSTANTS that can easily be processed at runtime.

I definitely give this concept a "+1" in case any of the language designers are listening!

A new context keyword maybe, or something comment-based, like the references.

You'd put it before the line of the type for which you want to export meta-data, so you can control what is exported.

/// <describe-type>
interface MyType {
...

It'd create a little object structure describing all the type info and export it (somewhere without runtime dependencies.. but where?). It'd be nice if it could refer to other exported types (if applicable).

Somebody with time to spend could venture to do this externally and use the TypeScript parser to get a source-tree and walk the nodes.

Find the annotations, transform the local data and export as JSON somewhere it can be loaded again. Or maybe do it a pre-processor to generate (typed) code to get compiled into the main code unit, that could be cool (meta-codeception :D).

Bonus-points if it can do json-schema.

Almost same thing right? Put some more detailed validation annotations in the code, export to details schemas and use existing schema validators on your objects during testing. Also use json-schema based stub/mock generators.

If I didn't had have a big project already I'd go for it. For inspiration look at TSLint (different thing but also a TypeScript tree walker).

One concrete feature suggestion that would be helpful: a language service method for getting declaration-style information about a type. We can get the type of an expression, we can jump to a definition (which may be an interface declaration or an implementation),
we can list completions, but I don't think there is a way to get an interface description.

Currently, the declarationEmitter is part of the compiler, and it works syntactically, by walking a single source file/AST in question. But interfaces can be extended over many modules, and it would be useful to have a semantic query: what is the
interface represented by this type name (at this source position in a project).

The assumption "nothing bad happening in the consctructor" is not very realistic with respect to object oriented code.

It wouldn't be possible to write new o without passing in constructor arguments, and constructing a new object simply to get its meta data seems wrong.

Furthermore this will need to work for interfaces, which is personally my primary requirement, because we would like to mock up TypeScript interfaces for our test harness.

In short, the meta data provision needs to be based on the static analysis of the code - not its runtime representation.

Regarding an output format, my preference is that the meta data should be compiled into a separate file ( a "myproj.meta" file, one file per project) rather than the
getType construct that @prohazko suggests.

As far as tooling goes: language service completions (intellisense support) seem to have most of the information you are asking for. So you could use the language service to make that information available to JS code, by pretending to complete something
typed to the interface you are interested in. Or you could employ my typescript-tools project (
https://github.com/clausreinke/typescript-tools ) to get the same information from the commandline, in JSON format.