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
fix: Serialize {enablePending: false} to --no-enable-pending #356
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks very much for this! Two small issues:
-
The commit messages with
fix
orfeat
appear in the changelog - would you be able to either:
-- force push a new message that explains the change for the changelog (something like "correct behaviour of enablePending: false in the verifier API")
-- let us know that you're ok with a squash merge to rewrite the message -
I've left a couple of review comments inline - the one I care about the most is the lint directives - we usually only allow
any
if a dependency is requiring it
src/spawn/arguments.ts
Outdated
} | ||
|
||
// eslint-disable-next-line @typescript-eslint/no-explicit-any | ||
type Mapping = string | ((val: any) => string[]); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd prefer not to turn off the lint warnings - perhaps this could be unknown
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When we change to unknown
here, we need annotate the mapping function argument type with unknown,
let argMapping: ArgumentMappings = {
enablePending: (enablePending: unknown) => [enablePending ? '--enable-pending' : '--no-enable-pending']
}
or do a explicit cast:
let argMapping = {
enablePending: (enablePending: boolean) => [enablePending ? '--enable-pending' : '--no-enable-pending']
} as ArgumentMappings;
Is that ok?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, I'd rather not do an explicit cast unless we have to, as (like any
) it's turning off the type checking. Maybe we can bring in an implicit type parameter or something - I'll have a play.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, right - so the type checking is already pretty nobbled by this point, because of the way the rest of the mapper works (there are also already some explicit casts in the branches above). This is one of the reasons we rewrote the mapper for the native verifier in the master branch.
I think unknown
is probably the better way- I'll push a commit that does that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(I prefer unknown
, because really we don't know what the type will be at that point. If we did rewrite this mapper from scratch, we'd want to do it in a way that the type information was retained. I think this is an artefact of this originally being pure JS)
I forgot to mention in the review above: This is nice work, thank you! |
Let's do squash merge. |
…ect what we know about the type
Thanks again for the PR - making it super easy to get this fixed. 10.17.0 is now released. |
This should fix pact-foundation/pact-js#782