enums not exported by grpc-protobufjs

[jhurwitz]

Problem description

When using the now-deprecated grpc.load, enums are exported and available in JS. When using @grpc/proto-loader, they are not.

Reproduction steps

Consider this simple .proto file:

syntax = "proto3";

enum BodyParts {
  HEAD = 0;
  SHOULDERS = 1;
  KNEES = 2;
  TOES = 3;
}

> const grpc=require('grpc');
undefined
> const protoLoader = require('@grpc/proto-loader');
undefined
> const oldProto = grpc.load('/path/to/file.proto');
undefined
> (node:16699) DeprecationWarning: grpc.load: Use the @grpc/proto-loader module with grpc.loadPackageDefinition instead
> oldProto
{ BodyParts: { HEAD: 0, SHOULDERS: 1, KNEES: 2, TOES: 3 } }
> const newProto = grpc.loadPackageDefinition(protoLoader.loadSync('/path/to/file.proto', {}));
undefined
> newProto
{}

As best as I can tell from the interfaces exported by grpc-protobufjs (https://github.com/grpc/grpc-node/blob/master/packages/grpc-protobufjs/src/index.ts), it looks like loadSync will never return enums.

At least according to protobufjs/protobuf.js#576, after loading the root and calling resolveAll, enums should be available via loadedRoot.lookup, but loadSync doesn't export the root so callers can't access them.

Environment

• Node v8.10.0
• gRPC 1.14.0-pre2
• @grpc/proto-loader 0.3.0

[nicolasnoble]

Have you checked the documentation of the new package about the various options available to pass to the loader, especially the part about enums? https://www.npmjs.com/package/@grpc/proto-loader

[jhurwitz]

Yes I have. I have, in exasperation, tried all options for enums as well as for all boolean options. Digging through source code, it looks like @grpc/proto-loader itself only consumes one of the options (includeDirs); the rest are passed along to and consumed by protobuf.js in the call root.loadSync(filename, options). In this library, the enums option controls whether enum values are returned as strings ("ONE") or numbers (1) (see eg this test: https://github.com/dcodeIO/protobuf.js/blob/2c5ef95818a310243f88ffba0331cd47ee603c0a/tests/data/convert.js#L492) but does not control whether enums are returned at all.

[murgatroid99]

The options you're referring to control how enum values are returned when deserializing messages. They do not change what type information is provided when parsing the proto file. The proto-loader library does not return the enum definition objects that you seem to be looking for.

[nicolasnoble]

Wait. Was this even available in grpc.load?

[jhurwitz]

The options you're referring to control how enum values are returned when deserializing messages. They do not change what type information is provided when parsing the proto file.

I believe we are in agreement there.

Wait. Was this even available in grpc.load?

Yes. See the code example I pasted in my initial bug report.

[nicolasnoble]

Right. The original behavior was then unfortunately a side effect from using protobufjs 5 that was probably leaking these out. It was never intended to leak any part of the proto definition beside the actual service definition. This isn't something we're going to change.

The deprecation notice will stay in effect until we release an hypothetical grpc 2.0, in which case it'll be removed. But also, grpc.load will still use the older protobufjs 5.0.3, while @grpc/proto-loader will somewhat use the latest version of protobufjs.

The solution for you if you want to have access to the contents of the proto definitions is to use protobufjs directly.

I'm closing this one as a "won't fix".