--allowJs and generated protocol buffers

[tamird]

Currently, Google's protocol buffer compiler at https://github.com/google/protobuf/tree/master/js generates code that looks something like:

/**
 * @fileoverview
 * @enhanceable
 * @public
 */
// GENERATED CODE -- DO NOT EDIT!

var jspb = require('google-protobuf');
var goog = jspb;
var global = Function('return this')();

goog.exportSymbol('proto.cockroach.util.hlc.Timestamp', null, global);


/**
 * Generated by JsPbCodeGenerator.
 * @param {Array=} opt_data Optional initial data array, typically from a
 * server response, or constructed directly in Javascript. The array is used
 * in place and becomes part of the constructed object. It is not cloned.
 * If no data is provided, the constructed object will be empty, but still
 * valid.
 * @extends {jspb.Message}
 * @constructor
 */
proto.cockroach.util.hlc.Timestamp = function(opt_data) {
  jspb.Message.initialize(this, opt_data, 0, -1, null, null);
};
goog.inherits(proto.cockroach.util.hlc.Timestamp, jspb.Message);
if (goog.DEBUG && !COMPILED) {
  proto.cockroach.util.hlc.Timestamp.displayName = 'proto.cockroach.util.hlc.Timestamp';
}

...
...
...

goog.object.extend(exports, proto.cockroach.util.hlc);

See also actual generated code.

I'm not really sure what the underlying cause is, but I can't seem to get any use out of the (presumed) types inferred from the JsDoc comments in this file.

By the way, is it possible to examine the result of --allowJs to see what the typescript compiler was able to infer?

[mhegazy]

I'm not really sure what's the underlying cause is, but I can't seem to get any use out of the (presumed) types inferred from the JsDoc comments in this file.

the system can not reason about such helper functions, e.g. goog.object.extend or goog.exportSymbol. so do not think you will get much out of it looking at this code.

By the way, is it possible to examine the result of --allowJs to see what the typescript compiler was able to infer?

open the file in VSCode, and hover over identifiers. it should show you what the TS type system thinks of them.

[tamird]

the system can not reason about such helper functions, e.g. goog.object.extend or goog.exportSymbol. so do not think you will get much out of it looking at this code.

Bummer. How do you feel about adding hooks for "teaching" TS about this class of helper e.g. via a definition file? (perhaps it's already possible to do this?)

open the file in VSCode, and hover over identifiers. it should show you what the TS type system thinks of them.

Is that the only way? Is there no way to do it outside of VSCode?

[mhegazy]

How do you feel about adding hooks for "teaching" TS about this class of helper e.g. via a definition file? (perhaps it's already possible to do this?)

sure. what kind of hooks? would be open to proposals.

Is that the only way? Is there no way to do it outside of VSCode?

you can use the compiler API and do it other forms. VSCode/Sublime/VS are just easier.

[evmar]

Within Google we use https://github.com/angular/clutz to generate TypeScript d.ts files from the Closure JS generated by the protocol compiler. Clutz hooks into the Closure compiler API so it understands the generated code well.

CC @rkirov

[tamird]

@evmar just to clarify, the process is:

1. use protoc to generate Closure JS
2. use clutz to generate typings from Closure JS
3. import Closure JS via clutz-generated typings into TS code
4. compile everything using Closure

Steps 3 and 4 are what's unclear to me. In particular, we are using SystemJS and plugin-typescript to do all our compilation in the browser. In other words, we really want to avoid having to run Closure on the output of the typescript compiler (because that's not really tractable). Is that possible?

[btgoodwin]

@evmar FWIW, +1 to this workflow problem.

I'm fighting my way through this as well in developing an ES2015 library that handles google protobufs. I've spent over a week trying to force protobufjs with @types/protobufjs only to have that route fall completely apart from endless packaging issues for how to deploy that library to the browser (tried jspm, webpack, systemjs).

I switched to google-protobuf only to find #1, I can't use import <whatever> = require('./module'); when my target module type is ES2015, so the CommonJS output is a no-go. #2, The Closure one is giving me similar problems as @tamird is showing. And those are the only two output options.

Is there a full, working example of this configuration anywhere in the wild that someone can reference?

[mhegazy]

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.