Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Generate an interface for the result of loadPackageDefinition #1159

Open
kasir-barati opened this issue Feb 2, 2025 · 0 comments
Open

Generate an interface for the result of loadPackageDefinition #1159

kasir-barati opened this issue Feb 2, 2025 · 0 comments

Comments

@kasir-barati
Copy link

kasir-barati commented Feb 2, 2025

loadPackageDefinition will load a gRPC package definition as a gRPC object hierarchy and in my E2E tests I need to define the types manually which is as you can guess it super tedious but important from the type-safety point of view. I do not like codes like this and usually you have a no any eslint rules somewhere in your project:

const proto = ProtoLoader.loadSync(
  join(__dirname, '../src/path-to-your/file.proto'),
) as any;
// Create Raw gRPC client object
const protoGRPC = GRPC.loadPackageDefinition(proto) as any;

Ref.

So right now I am doing something like this as a workaround:

import { ChannelCredentials } from '@grpc/grpc-js';
import {
  GrpcUserServiceClient,
  User,
} from '../../../nestjs-client/src/assets/interfaces/user.interface';
import { GrpcErrorResponse } from './shared.type';

interface GrpcUserService {
  new (
    url: string,
    credentials: ChannelCredentials,
  ): GrpcUserServiceClient;
}
export interface LoadPackageDefinition {
  /**@description The name of our package which we wrote in our `user.proto` file. */
  user: {
    /**@description Comes from the name we gave to this service in our `user.proto` file. */
    GrpcUserService: GrpcUserService;
  };
}
// ...
const {
  user: { GrpcUserService },
} = loadPackageDefinition(
  packageDefinition,
) as unknown as LoadPackageDefinition;

Ref for the interface and here is the ref for the second part.

So my point is that this can be done in this lib. Right like where I am still using the type generated by this lib, e.g. here.

Do you think this can be added too? I mean right now my solution and any is prone to human errors and my types are hard to maintain over time (more protobuf files means more custom types and with each breaking change I have to go over all of them).

Appreciate your attention and replies 💮.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant