typecheck vats package #8596
typecheck vats package #8596
Conversation
| @@ -1,3 +1,4 @@ | |||
| /* eslint-disable @typescript-eslint/prefer-ts-expect-error -- accomodate different type search depths */ | |||
There was a problem hiding this comment.
How much type-checking coverage are we losing here?
There was a problem hiding this comment.
this is just to allow using ts-ignore instead of ts-expect-error
| @@ -152,7 +152,8 @@ const facetHelpers = (zcf, paramManager) => { | |||
| * | |||
| * @see {makeDurableGovernorFacet} | |||
| * | |||
| * @param {{ [methodName: string]: (context?: unknown, ...rest: unknown[]) => unknown}} limitedCreatorFacet | |||
| * @template {{ [methodName: string]: (context?: unknown, ...rest: unknown[]) => unknown}} LCF | |||
| * @param {LCF} limitedCreatorFacet | |||
There was a problem hiding this comment.
There seems to be an endless amount of refinement to do for the types for governance.
I wonder if really complex types is like really complex documentation: it suggests searching for a simpler design.
There was a problem hiding this comment.
Indeed. The design we shipped with was somewhat rushed. Making it durable is also rushed (and incomplete). When making it durable we could simplify, or do that in a next phase.
| @@ -1,4 +1,3 @@ | |||
| // @ts-check | |||
There was a problem hiding this comment.
I'm curious why this should be taken out.
A comment would be ideal.
There was a problem hiding this comment.
oh. the tsconfig is opt-out now.
I'm uneasy about making such signals implicit. But I suppose it's better than having the next person forget make a new file and forget to include it.
| "atLeast": 90.86 | ||
| "atLeast": 90.88 |
turadg
force-pushed
the
ta/typecheck-scripts
branch
from
197f9e4 to
ac65945
Compare
|
@turadg - This PR appears to be stuck. It's had a merge label for > 24 hours |
turadg
force-pushed
the
ta/typecheck-scripts
branch
from
ac65945 to
f8cd24b
Compare
| function providePromiseWatcher( | ||
| kindHandle, | ||
| fulfillHandler = x => x, | ||
| rejectHandler = x => { | ||
| throw x; |
There was a problem hiding this comment.
@FUDCo removing this throw make sense to you? I think when when a rejectHandler throws that ends up as an unhandled promise rejection
There was a problem hiding this comment.
At first glance I thought you were right, but on further inspection I'm not sure that's so (though I'm not deeply confident of that conclusion). In particular, it looks to me like there's a call chain from startVat that can result in somebody catching the exception.
On the other hand, I think the default fulfillHandler is questionable, since from the way it's invoked it doesn't look to me like there's ever going to be anybody positioned to receive the return value.
checkJs is true now in this package
turadg
force-pushed
the
ta/typecheck-scripts
branch
from
8a04be6 to
1d22782
Compare
…ndler (#9507) refs: #8596 ## Description Reverts a behavioral change questioned in #8596 (comment), which was indeed not appropriate. If the reject handler is missing, it should result in an unhandled rejection. ### Security Considerations None ### Scaling Considerations None ### Documentation Considerations None ### Testing Considerations No coverage ### Upgrade Considerations Maintains currently deployed behavior on mainnet
…ndler (#9507) refs: #8596 ## Description Reverts a behavioral change questioned in #8596 (comment), which was indeed not appropriate. If the reject handler is missing, it should result in an unhandled rejection. ### Security Considerations None ### Scaling Considerations None ### Documentation Considerations None ### Testing Considerations No coverage ### Upgrade Considerations Maintains currently deployed behavior on mainnet
…ndler (#9507) refs: #8596 ## Description Reverts a behavioral change questioned in #8596 (comment), which was indeed not appropriate. If the reject handler is missing, it should result in an unhandled rejection. ### Security Considerations None ### Scaling Considerations None ### Documentation Considerations None ### Testing Considerations No coverage ### Upgrade Considerations Maintains currently deployed behavior on mainnet
refs: #8445
Description
#8488 had a hard to find bug that would have been easier with typechecking. The proposal wasn't being type-checked because in @agoric/vats the typecheck is opt-in.
This changes it to opt-out. I confirmed with
yarn type-coveragethat it doesn't lose any, and in fact it goes up.This also provides some type annotations that might also have helped detect the bug.
Security Considerations
n/a
Scaling Considerations
n/a
Documentation Considerations
Self-documenting
Testing Considerations
CI
Upgrade Considerations
n/a