Nested message named "Function" now ends up as *_FunctionMessage in generated ts.

[jdillon]

Caused by da048a1#diff-d34bf5280590ab473d1ad488821d664a0746c3459a2d1f3c2d7ea6037be2b042R63
from PR: #1110

This change causes nested messages to break from previous behavior.

message Scope {
   message Function {
   }
}

Used to render as interface Scope_Function but now will render as interface Scope_FunctionMessage ... which is erroneously appending Message to this type name.

[jdillon]

Special handling for messages that conflict with special Javascript names (Function, Date) probably should only do so if they are not nested messages?

[stephenh]

Hi @jdillon , ah yeah, agreed we don't need the ...Message suffixing for nested messages.

If you could submit a PR that adds that check (where the builtIns array is checked and Message is conditionally appended), that would be great! Thanks!

[jdillon]

@stephenh I can look, though at first glance I'm not sure how to tell if message: DescriptorProto is a nested message or not. so if you have any hints, then I can put a simple PR together for you.

[stephenh]

Np! I'm 80% sure that protoPrefix is only non-empty for nested messages:

  messages.forEach((message, index) => {
    // I.e. Foo_Bar.Zaz_Inner
    const protoFullName = protoPrefix + message.name;
    // I.e. FooBar_ZazInner
    const tsFullName = tsPrefix + maybeSnakeToCamel(messageName(message), options);

That call-site also has a isRootFile local variable that is probably true for top-level messages, and false for nested messages.

Those are the two things I'd try, and hopefully one of the two works.

[halkeye]

I have a PR up, i didn't see the new ticket created

#1123

[stephenh]

Fixed in #1123 , thanks @halkeye !

[jdillon]

thank you!