chore: add type-safe ESLint #119
Conversation
gagik
force-pushed
the
gagik/eslint-type
branch
from
1631038 to
003fe9c
Compare
gagik
force-pushed
the
gagik/eslint-type
branch
from
003fe9c to
7164709
Compare
| try { | ||
| await integration.mcpClient().callTool({ name, arguments: arg }); | ||
| expect.fail("Expected an error to be thrown"); | ||
| throw new Error("Expected an error to be thrown"); |
There was a problem hiding this comment.
this was not working correctly so we had the false impression that extra fields are problematic with our zod setup; they're not so I removed places where we were using that as an invalid arg scenario
| "strictNullChecks": true, | ||
| "esModuleInterop": true, | ||
| "types": ["node"], | ||
| "types": ["node", "jest"], |
There was a problem hiding this comment.
This just seems to be the best way to get VSCode to stop complaining about the types once in a while but I think can work without too as long as others are represented
Pull Request Test Coverage Report for Build 14665235990Details
💛 - Coveralls |
| expect.fail("Expected an error to be thrown"); | ||
| throw new Error("Expected an error to be thrown"); | ||
| } catch (error) { | ||
| expect((error as Error).message).not.toEqual("Expected an error to be thrown"); |
There was a problem hiding this comment.
Isn't the assertion just below sufficient? I don't imagine Error is an instance of McpError.
There was a problem hiding this comment.
it is but then the error message is more confusing (it just says expected McpError got Error which originally made me think it was erroring differently instead of not erroring at all). I want to differentiate an external error from the intentional "did not end up erroring" error
gagik
force-pushed
the
gagik/eslint-type
branch
from
c239276 to
140830c
Compare
Fixes #113
Largely did the minimum viable actions needed to get the linting to pass.
Also added
expectDefinedso we don't need to keep asserting our types manually.