feat: completely factorize SubtleCrypto.generateKey() #2050
Conversation
|
Thanks for the PR! This section of the codebase is owned by @saschanaz - if they write a comment saying "LGTM" then it will be merged. |
hkleungai
force-pushed
the
crypto-factorize-subtle.generateKey
branch
from
53beb15 to
0dc3d22
Compare
inputfiles/overridingTypes.jsonc
Outdated
| "typeParameters": [ | ||
| { | ||
| "name": "T", | ||
| "extends": "{ name: string }" | ||
| } | ||
| ], | ||
| "param": [ | ||
| { | ||
| "name": "algorithm", | ||
| "overrideType": "string | T" | ||
| } | ||
| ], |
There was a problem hiding this comment.
I believe this generic is needed, or else the fallback signature will fail to capture poosibly-work algorithm object with extra attibutes other than name.
There was a problem hiding this comment.
No-one's raised any issues with AlgorithmIdentifier; this seems an arbitrary modification.
There was a problem hiding this comment.
See https://tsplay.dev/Ndp9MN, in which the method call is taken from types/node/test/globals-non-dom.ts in DefinitelyTyped.
Without the use of generic, mismatched algorithm and keyUsages[] params would yield a confusing error, saying the code is violating the wrong overload.
But with the generic, such mismatch will pass and give Promise<CryptoKeyPair | CryptoKey>. It may not be the best way to typecheck, but I think this generic could help prevent certain possible breaking change.
There was a problem hiding this comment.
I don't really understand – the whole point of this PR is that it breaks in this case?
The example provided is a mismatch with the accepted usages of the new HmacKeyGenParams signature, and is genuinely incorrect usage that would error at runtime. If we're going to provide a route for the new keyUsages constraints to be ignored anyway, then there's surely there's no real advantage to these changes?
(We can always modify that test – I suspect that the selection of keyUsages there was entirely arbitrary.)
There was a problem hiding this comment.
I think you are right. I have repushed the PR to remove the generics.
hkleungai
force-pushed
the
crypto-factorize-subtle.generateKey
branch
from
0dc3d22 to
a6b6305
Compare
Opening this PR in favor of this comment from @Renegade334 in my another PR in DT repo.
Since https://nodejs.org/api/webcrypto.html#cryptokeyusages lists the usages in its own table, and it is closely aligned to the MDN reference in https://developer.mozilla.org/docs/Web/API/SubtleCrypto/generateKey, I believe it is possible to raise such change to
@types/webas well.Potentially we can do this to other methods in the key-usages table, but let's see how reviewers think about this change, then we may perform the refactoring incrementally in subsequent PRs.
Fallback signature is also updated, in favor of matching richer shape of possible
Algorithmobject.