profile
viewpoint
Steven Silvestri ssilve1989 TruMid @Omnistac New York http://ssilve1989.github.io Software Engineer

ssilve1989/redux-session-manager 3

Redux Store Enhancer that serializes state to sessionStorage

ssilve1989/react-redux-dialog 2

React Dialog component for use in Redux apps

ssilve1989/redux-session-manager-middleware 1

Manage your client-side redux application state

JIoffe/Flame-Broiled-Fury-BETA 0

2D side scrolling shooter inspired by Megaman and Commander Keen. Unfinished - will be revisted with newer technology.

ssilve1989/amcharts3-react 0

Official amCharts V3 React component

ssilve1989/config 0

Configuration module for Nest framework (node.js) 🍓

ssilve1989/cz-cli 0

The commitizen command line utility.

ssilve1989/deep-learning 0

Repo for the Deep Learning Nanodegree Foundations program.

fork ssilve1989/config

Configuration module for Nest framework (node.js) 🍓

https://nestjs.com

fork in 8 days

issue openednestjs/config

ValidationSchema does not respect configuration provided to `load`

<!-- PLEASE HELP US PROCESS GITHUB ISSUES FASTER BY PROVIDING THE FOLLOWING INFORMATION.

ISSUES MISSING IMPORTANT INFORMATION MAY BE CLOSED WITHOUT INVESTIGATION. -->

I'm submitting a...

<!-- Please search GitHub for a similar issue or PR before submitting. Check one of the following options with "x" --> <pre><code> [ ] Regression <!--(a behavior that used to work and stopped working in a new release)--> [x] Bug report [ ] Feature request [ ] Documentation issue or request [ ] Support request => Please do not submit support request here, instead post your question on Stack Overflow. </code></pre>

Current behavior

<!-- Describe how the issue manifests. --> Given the following code:

import { Module } from '@nestjs/common';
import { ConfigModule } from '@nestjs/config';
import Joi from '@hapi/joi';

const configuration = () => ({
  foo: 'bar',
});

@Module({
  imports: [
    ConfigModule.forRoot({
      validationSchema: Joi.object({
        foo: Joi.string().required(),
      }),
      load: [configuration],
    }),
  ],
})
export class AppModule {}

The following error is produced

Error: Config validation error: "foo" is required
    at Function.forRoot (/Users/stevensilvestri/dev/playground/node_modules/@nestjs/config/dist/config.module.js:43:23)
    at /Users/stevensilvestri/dev/playground/packages/ts-compile-targets/src/app.module.ts:11:18
    at Object.<anonymous> (/Users/stevensilvestri/dev/playground/packages/ts-compile-targets/src/app.module.ts:44:3)
    at Module._compile (internal/modules/cjs/loader.js:1200:30)
    at Module.m._compile (/Users/stevensilvestri/.config/yarn/global/node_modules/ts-node/src/index.ts:473:23)
    at Module._extensions..js (internal/modules/cjs/loader.js:1220:10)
    at Object.require.extensions.<computed> [as .ts] (/Users/stevensilvestri/.config/yarn/global/node_modules/ts-node/src/index.ts:476:12)
    at Module.load (internal/modules/cjs/loader.js:1049:32)
    at Function.Module._load (internal/modules/cjs/loader.js:937:14)
    at Module.require (internal/modules/cjs/loader.js:1089:19)

Expected behavior

<!-- Describe what the desired behavior would be. --> No error should be thrown

Minimal reproduction of the problem with instructions

<!-- Please share a repo, a gist, or step-by-step instructions. --> see snippet above

What is the motivation / use case for changing the behavior?

<!-- Describe the motivation or the concrete use case. --> The configuration is providing the value, it should not fail validation when it is provided.

Environment

<pre><code> Nest version: 7.0.13 <!-- Check whether this is still an issue in the most recent Nest version -->

For Tooling issues:

  • Node version: XX <!-- run node --version -->
  • Platform: <!-- Mac, Linux, Windows -->

Others: <!-- Anything else relevant? Operating system version, IDE, package manager, ... --> </code></pre>

created time in 8 days

pull request commentprotocolbuffers/protobuf

Add Javascript convenience getters/setters.

bump?

travigd

comment created time in a month

issue commentprotobufjs/protobuf.js

Installation errors running CLI

This is so annoying. Installing packages dynamically!? it should be avoided.

Any update on this? That is 100% accurate in that it should be avoided, this is crazy.

jakelauer

comment created time in a month

issue commentnestjs/nest

[Microservices] Move from grpc to @grpc/grpc-js package

Any update on this? Looks like the PR just has small conflicts to resolve?

gperdomor

comment created time in a month

issue commentnestjs/nest

No way to get client IP in gRPC microservice

Also interested in this

Livan-pro

comment created time in a month

startedTimVosch/istio-workshop

started time in a month

create barnchssilve1989/bazel-ts

branch : ts-proto

created branch time in 2 months

create barnchssilve1989/bazel-ts

branch : master

created branch time in 2 months

created repositoryssilve1989/bazel-ts

created time in 2 months

issue commentstephenh/ts-proto

Incompatible Wrapper Types with Nest.js (protobufjs)

Teach NestJS's protobuf serializer about ts-proto's "different" approach to well-known types

There seems to be an option in Nest's grpc options to use a different proto-loader, but there's no documentation on what implementing a custom-loader would look like.

ssilve1989

comment created time in 2 months

issue commentstephenh/ts-proto

Incompatible Wrapper Types with Nest.js (protobufjs)

@stephenh I've opened up a reproduction repo here: https://github.com/ssilve1989/ts-proto-issue-69

ssilve1989

comment created time in 3 months

push eventssilve1989/ts-proto-issue-69

Steven Silvestri

commit sha d8ff82982f488c677bb5c91ea61d31585f7331e8

initial commit

view details

push time in 3 months

create barnchssilve1989/ts-proto-issue-69

branch : master

created branch time in 3 months

created repositoryssilve1989/ts-proto-issue-69

created time in 3 months

issue openedstephenh/ts-proto

Incompatible Wrapper Types with Nest.js (protobufjs)

When using Google's Well-Known Types with Nest (or just plain protobuf) the types generated from ts-proto fail to be parsed.

Given this protobuf

syntax = "proto2"
import "google/protobuf/wrappers.proto";

message MonitorHelloRequest {
    optional google.protobuf.StringValue name_prefix = 2;
    optional google.protobuf.Int64Value limit = 3;
}

we get a typescript interface of


export interface MonitorHelloRequest {
  namePrefix: string | undefined;
  limit: number | undefined;
}

which seems fine. But when attempting to use that as a message that is parsed by a server using protobufjs (nest in this case)

You get the error

TypeError: MonitorHelloRequest.namePrefix: object expected

This is because protobufjs is actually expecting that interface to be


export interface MonitorHelloRequest {
  namePrefix: { value: string } | undefined
  limit: { value: number } | undefined;
}

it is unclear to me who is right here as I can see the argument for either. This was referenced on https://github.com/protobufjs/protobuf.js/issues/1042 and several other issues but there does not seem to be any update in a very long time from protobufjs on the matter

created time in 3 months

issue commentprotobufjs/protobuf.js

Unable to use Google well known types

bump

respinha

comment created time in 3 months

delete branch ssilve1989/ts-proto

delete branch : fix/nest-grpc-methods

delete time in 3 months

issue commentstephenh/ts-proto

NESTJS - `Error: 12 UNIMPLEMENTED: The server does not implement this method`

@lukas-andre Briefly skimmed over this issue and seems related to a PR i've opened to address this. https://github.com/stephenh/ts-proto/pull/68

My PR has tested the cases of rpc calls with:

  • request -> stream
  • stream -> stream
  • stream -> request
  • request -> request
jessequinn

comment created time in 3 months

push eventssilve1989/ts-proto

Steven Silvestri

commit sha 3d61d7f142c04642bc846d29323f1146c9222d36

fix: fixes how grpc methods are determined for nest

view details

push time in 3 months

PR opened stephenh/ts-proto

fix(nestjs): fixes grpc controller decorator

First off let me say I am very grateful to see NestJS support here, so thanks! I've been doing similar things in a custom tool alongside your ts-proto package but glad to see it in here now.

This fixes the controller methods decorator. Prior to this fix it was using the wrong decorator for certain types of methods.

Given the following proto that demonstrates all possible combinations of rpcs:

service GreeterService {
    rpc SayHello (HelloRequest) returns (HelloReply) {}
    rpc SayHelloToAll (stream HelloRequest) returns (stream HelloReplyMessage) {}
    rpc MonitorHellos (MonitorHelloRequest) returns (stream MonitorHelloResponse) {}
    rpc MonitorHellosWithSnapshot (MonitorHelloRequest) returns (stream MonitorHelloResponseOrSnapshot) {}
    rpc BroadcastHellos (stream HelloRequest) returns (HelloCounter) {}
}

rpc calls that take in a regular request, regardless of if they return a stream, need to be decorated with GrpcMethod() in Nest.

rpc calls that take in a stream, regardless of what they return should be decorated with GrpcStreamMethod()

Note

There was no yarn.lock in this repository which i believe caused some issues when trying to initialize this repository and i've seen some tests fail as a result of that, probably. I also had to add a tsconfig rule to remove some TS errors I was seeing.

+5 -4

0 comment

3 changed files

pr created time in 3 months

create barnchssilve1989/ts-proto

branch : fix/nest-grpc-methods

created branch time in 3 months

fork ssilve1989/ts-proto

An idiomatic protobuf generator for TypeScript

fork in 3 months

more