Conversation
Collaborator
|
Thanks @zunixport, the digit mismatch is real. This repo is a read-only mirror, so we've recreated the fix in our internal monorepo with you credited as co-author. It ships in the upcoming @opensea/sdk 12.11.1. One correction: the old type already mapped Closing this PR since the change now lives in the monorepo. Appreciate it! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Snakeizeputs a spurious underscore before every digitcamelToSnakematches/[A-Z]/, but the type-level mapper decided "is this an uppercase letter?" withHead extends Uppercase<Head>.Uppercaseis the identity on digits and on anything without a case, so"1" extends Uppercase<"1">istrueand every digit read as an uppercase letter.chain2Idchain_2_idchain2_iderc721TokenIderc_7_2_1_token_iderc721_token_idA leading underscore is affected by the same cause (
Uppercase<"_">is"_"):Snakeize<{ _private: number }>resolved to__privatewhile the runtime leaves_privatealone.Why it matters
Snakeize<T>is exported from the package root and describes outgoing request bodies, so this is the request-side counterpart of the response-casing mismatch documented inAGENTS.mdrule 9 — and the compiler cannot catch it:snakeizeKeysDeep({ chain2Id: x })is typed as{ chain_2_id: string }body.chain_2_idtscis satisfiedchain2_id, so the read isundefinedA value that type-checks and comes back
undefinedis the worst of the two failure modes; the type is supposed to describe the value the caller actually gets.Fix
Compare against
Lowercaseinstead. That is true for exactly the charactersLowercaserewrites, which is the set the runtime/[A-Z]/matches. The existing cases are unchanged:MyKeyis stillmy_key,URLis stillu_r_l.Tests
Extended the existing
Snakeize<T>block intest/utils/case.spec.tswith the digit case (a type assertion plus a runtime assertion, which is what vitest actually runs) and the leading-underscore case. The type assertions are read bycheck-types, as the file's other type tests already note.