Refactor/typescript enable stricter typescript compiler flags - #440
Merged
mikewheeleer merged 2 commits intoJul 26, 2026
Conversation
Contributor
|
nice work — merging now |
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.
closes #359
Summary
Enable three stricter TypeScript compiler flags —
noUncheckedIndexedAccess,exactOptionalPropertyTypes, andnoImplicitOverride— and fix the resulting type errors with real narrowing (control-flow guards, nullish coalescing) rather than non-null assertions.The flags were already set in
tsconfig.jsonbut the codebase had 4 latent type errors from prior work that predated the flag activation. This PR resolves those errors and expands test coverage to prevent regressions.Related Issue
Closes #359
Validation
npm run buildnpm run lintnpm testChanges
src/index.ts— 4 type-error fixesaggregatePairStats(line ~2189)k.split("::")destructuring yields(string | undefined)[]undernoUncheckedIndexedAccessparts[0]/parts[1]variables guarded bysource !== undefined && destination !== undefined/api/v1/pairs/bulk(line ~2367)config.bulkMaxItemsisnumber | undefinedunder indexed access onRecord<string, number>?? DEFAULT_BULK_MAX_ITEMSfallback/api/v1/quote/bulk(line ~2453)DEFAULT_BULK_MAX_ITEMSconstantIntroduced
DEFAULT_BULK_MAX_ITEMS = 100as a named constant alongside the existingBULK_ABSOLUTE_MAX.src/__tests__/stores.test.ts— expanded coverage (12 → 69 tests)Added test suites that exercise the exact scenarios the stricter flags protect against:
noUncheckedIndexedAccess):config[key],Map.get(),Array.at(),pairRegistryiteration with split + guardexactOptionalPropertyTypes):ApiKeyRecordwith/withoutscopes,rotatedAt,graceExpiresAt,expiresAt,lastUsedAtapiKeyPrefix,generateApiKeySalt,hashApiKeySecret,verifyApiKeySecretisPaused,isReadOnly,setPaused,setReadOnlyisHydrating,setHydratinggetSnapshot,hydrateFromSnapshot(including legacy key rejection, malformed input tolerance)KNOWN_EVENT_TYPES,EVENT_LOG_CAP,EVENT_LOG_CAP_MAX,RATE_BUCKETS_MAX_IPS,HEALTH_PROBE_KEYChecklist
.envfiles, or private credentials.Security Notes
No new security assumptions introduced. The
??fallback forbulkMaxItemsis defensive — it prevents a crash ifconfig.bulkMaxItemswere ever absent (which cannot happen under normal operation becausedefaultConfig()always sets it). The split guard inaggregatePairStatssilently skips malformed pair keys instead of crashing, which is consistent with the existing defensive patterns in the codebase.