ui: Smooth out issues with generated protobuffer definitions.

[mrtracy]

In the next version of our admin UI, we are now generating proto-buffer definitions directly from .proto files. This is accomplished using a couple of open-source tools (proto2js, Proto2Typescript). Unfortunately, there are incompatibilities between the output of Proto2Typescript and the systemjs typescript plugin (plugin-typescript), and we have worked around some of these issues with "hacks".

We should figure out the best way to improve the protobuffer generation process so that these hacks are not necessary.

[maxlang]

@tamird @mrtracy can you enumerate the hacks?

[tamird]

I don't think it's necessary to enumerate the hacks. Looking ahead slightly, I have a branch in which I use protoc --js_out to generate CommonJS which includes JsDoc comments, instead of the current mix of tools.

It's also my understanding that typescript@next supports importing javascript without definition files, and also pulling type information from JsDoc comments. My current understanding of this is "tracked" upstream: microsoft/TypeScript#9317.

The next step here is to experiment with typescript@next on that branch.

[maxlang]

Gotcha. I'll assign to you for now.

[tamird]

Quick update on this: the code produced by https://github.com/google/protobuf/tree/master/js is not yet suitable for use directly with the typescript compiler (even typescript@next).

tsc --allowjs works when all the imports are rewritten to point to the generated commonjs, but the JsDoc-based inference is not enough to make those files usable. In particular, Google's closure-style exports are not picked up by typescript. Progress on this front is tracked upstream in https://github.com/google/protobuf/issues/1231.

[tamird]

More update: filed microsoft/TypeScript#9509.