-
Notifications
You must be signed in to change notification settings - Fork 33
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
Type issue with ServerReflectionService #611
Comments
Remark: reverting to these versions fixes the problem for now:
|
…one. checks listing and getting reflection in a naive way but provides some coverage. typescript seems to compile OK. tried but failed to repro deeplay-io#611
Hi! We'll probably need to know more about your build environment, typescript versions, other dep versions, maybe tsconfig, etc. I added tests which use the same syntax you provided. But I failed to reproduce in #612 See if you can repro locally:
Edit: the new tests have been merged to master, so I updated the commands above to help diagnose if it is local to your host environment or instead your build environment for just your project |
I accidentally stumbled upon a repro of this while working on another change which would address #610 Unfortunately, I'm having a hard time making a minimal repro from my larger commit in progress so far, but I figured I'd update that I have seen what you mean. @UncleSamSwiss Can you please post your typescript version, which compiler/bundler you are using, and the command with plugins you are using to generate your ServerReflection proto? I think it is something to do with the interplay between gRPC-js, typescript version, and the generated proto. The reflection.proto was generated as:
I've been working on resolving this by generated differently in my commit by rewriting the package to use the nicer generated protos:
But even if using different generation works for me in this one case, it means that that old generation format is (maybe?) broken in general, larger the scope of server-reflection package. |
It's been messy, but I was able to make a repro and pushed it to a repos. The only real delta is the yarn version used.
Repro:
Partial output:
|
where /tmp/good is the 1.22.22 version result:
Given that the files are the same, this is a problem with the packages installed. Possibly looking at yarn-lock-diffed-version-info-only.diff.txt The one that stands out is this
|
Seems 100% related to Yarn PnP. Turning it off and no errors:
@aikoven I'm wondering if you wouldn't mind taking a look from here. Hopefully this gives you a solid starting point. You have demonstrably shown your typescript voodoo skills to be excellent by writing nice-grpc itself. And you've managed to create a corner case that broke the wildly popular Yarn PnP. ;) I don't think I am expert enough at the type system to know what we could have caused to occur easily. If we can make the PoC even smaller, maybe we can report it to the Yarn team directly. This unfortunately partially blocks another commit I am working on, which does do the dual ESM and CJS output because I depended on upgrading to yarn2+ in it already :/ Let me know what you think if you have cycles to identify the root cause. |
Oh, and just to clear up a hypothesis: The grpc-js 1.10.x change itself didn't likely cause the breakage the reporter is mentioning. Instead it was likely this: https://github.com/deeplay-io/nice-grpc/pull/608/files which added The caveat is that by being explicit, it seems we may have broke someone else. I'm surprised by that though. I've very curious how the OP made this happen. Maybe they brought in nice-grpc via a git submodule. Consuming the compiled NPM distribution I wouldn't have imagined to cause any problem because they aren't compiling anything in nice-grpc. Maybe @UncleSamSwiss can chime in with more details about how they were depping on nice-grpc and setup their build environment. |
I will have access to the code again on Tuesday, but what I can already say is:
I'll report more once I can look at the code again. |
Here is some additional information:
import {
CallContext,
ServerError,
ServerMiddlewareCall,
Status,
createServer,
} from "nice-grpc";
import {
ServerReflection,
ServerReflectionService,
} from "nice-grpc-server-reflection"; None of the used types in the failing code are our own and none of them are related to code generated by |
The errors started popping up in our GitHub Actions first (after the merge of the updated dependencies from renovate-bot), so it seems not to be related to a specific local setup (which is Devcontianer btw). Our {
"extends": "../../tsconfig.base.json",
"files": [],
"include": [],
"references": [
{
"path": "./tsconfig.app.json"
},
{
"path": "./tsconfig.spec.json"
}
],
"compilerOptions": {
"esModuleInterop": true,
"resolveJsonModule": true
}
}
{
"extends": "./tsconfig.json",
"compilerOptions": {
"outDir": "../../dist/out-tsc",
"module": "commonjs",
"types": ["node"]
},
"exclude": [
"jest.config.ts",
"src/**/__mocks__/*.ts",
"src/**/*.spec.ts",
"src/**/*.test.ts",
"src/**/*.mock.ts"
],
"include": ["src/**/*.ts"]
}
{
"compileOnSave": false,
"compilerOptions": {
"rootDir": ".",
"sourceMap": true,
"declaration": false,
"moduleResolution": "node",
"emitDecoratorMetadata": true,
"experimentalDecorators": true,
"importHelpers": true,
"target": "es2015",
"module": "esnext",
"lib": ["es2021", "dom"],
"skipLibCheck": true,
"skipDefaultLibCheck": true,
"alwaysStrict": true,
"strictNullChecks": true,
"noImplicitAny": true,
"baseUrl": ".",
"paths": {
"<confidential>": ["<confidential>"]
}
},
"exclude": ["node_modules", "tmp", "tools"]
} |
As of the latest versions (see below) the following code doesn't work anymore in typescript:
Error message:
Versions:
The text was updated successfully, but these errors were encountered: