Expose `TypeChecker.getTypeOnlyAliasDeclaration` or similar API to detect if a symbol is a "value" or a "type"

🔍 Search Terms

"type checker", "getTypeOnlyAliasDeclaration", "detecting value vs type on a symbol"

✅ 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 isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

It would be nice if the compiler would expose TypeChecker.getTypeOnlyAliasDeclaration or similar function that would help to detect if a given symbol is a type or a value (e.g. a class is a type if it was imported/exported via import-type/export-type syntax.

📃 Motivating Example

I'm maintaining https://github.com/timocov/dts-bundle-generator and have the following issue https://github.com/timocov/dts-bundle-generator/issues/290. My problem is that I need to somehow detect if a module export symbol is a type or a value so I can detect whether the type of a symbol changes since its original declaration and its actual export so I can generate type export instead of exporting a value. I asked in the community discord and @jakebailey pointed that the type checker has function getTypeOnlyAliasDeclaration that might help. I've checked with my test cases and it seems it works like a charm. I understand that this function itself might not be what you actually want to expose from the API so I'm happy with either solution.

Also I'm happy to contribute for this feature.

💻 Use Cases

1. What do you want to use this for? Use it in the tool dts-bundle-generator to address mentioned issue
2. What shortcomings exist with current approaches? Nothing seems exist
3. What workarounds are you using in the meantime? I can use the internal (not exposed) API for a while and hope it won't change in the future