Consider exporting the TS interfaces for messages under a different identifier from the runtime value

[jcready]

Consider the following proto message:

message Example {}

It will generate a file with:

export interface Example {}
// ... Example$Type class definition
export const Example = new Example$Type();

Then in application code you'd import it:

import { Example } from 'some/path';

This has two negative effects (especially inside vscode, but likely affects other editors as well):

1. Hovering over the Example in application code results in two aliases: one interface and one value.

    (alias) interface Example
    (alias) const Example: Example$Type
    import Example
    ---
    @generated — from protobuf message some.path.Example
    ---
    @generated — MessageType for protobuf message some.path.Example
   

2. Attempting to "Go to Definition" results in a popup dialog with two different possible results since there isn't a single location to go to.

My proposal would be to prefix/suffix the interface with something so that the runtime value is distinct from the type interface. Perhaps just a leading I such that the generated file would be:

export interface IExample {}
// ... Example$Type class definition
export const Example = new Example$Type();

This change would certainly be a breaking change so I wouldn't expect it until a major version bump. I also don't know how this would impact naming conflicts e.g. perhaps someone has message Example {} and message IExample {} in the same file.

[timostamm]

The behavior in JetBrains IDEs is a bit similar - not ideal. So far I couldn't think of a naming scheme that seemed really convincing to me. I've considered (based on message Example):

Interface	Type
Example	ExampleType
Example	ExampleDescriptor
Example	ExampleDesc
IExample	Example

I dismissed IExample rather early. It is a convention to prefix interfaces in C# and Java, but a controversial one, and it does not seem to translate well to TypeScript. It is perfectly possible that my dismissal was premature, though.

I hope we can get more user feedback on this before we make a change.