refactor(core): take the remaining duplicated types from @seamless-auth/types - #135
Merged
Conversation
…th/types SeamlessUser is now an alias of the types package's MeUser, and the eight messaging wire shapes are re-exported rather than declared again. Each was field for field identical to a definition that already existed upstream, which is the drift that package exists to prevent. The transport interfaces and adopter-facing configuration stay here: they carry provider implementations and adapter options, not wire shapes. No public API change and no runtime cost. Every name is still exported under the same name, the re-exports are type-only, and the built output still imports only @seamless-auth/types/role/matching. Verified by compiling the whole public type surface against real values. Closes #133
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 #133.
Change
Two duplications removed, both types that
@seamless-auth/typesalready defines:SeamlessUseris now an alias ofMeUser. The name staysSeamlessUserhere because that is what adapters and adopters import, so nothing renames.Eight messaging wire shapes are re-exported rather than declared:
MessagingChannel,DeliveryResult,EmailMessage,SmsMessage,SendOtpEmailInput,SendOtpSmsInput,SendMagicLinkEmailInput,AuthDeliveryInstruction.I compared each against the upstream schema field by field before substituting, including the ones easy to get wrong:
SendOtpSmsInput.tokenisstring | numberon both sides,DeliveryResult.rawis optionalunknown, andAuthDeliveryInstructionis the same three-member discriminated union onkind.What stays here, deliberately
EmailTransport,SmsTransport,AuthMessageOverrideContext,AuthMessageOverrides,AuthMessagingHandlers,SeamlessAuthMessagingOptions. These carry provider implementations and adopter configuration rather than wire shapes, so they belong to this package. That split is what the "Related" note on #118 predicted.packages/core/src/authMessaging.tsdrops from 114 to 83 lines and now reads as the contract it is: the wire shapes come from upstream, the transports are ours.No public API change, no runtime cost
Verified rather than assumed:
@seamless-auth/coreand both adapters. Compiled the whole public type surface against real values (constructing anEmailMessage, aSendOtpSmsInputwith a numeric token, anAuthDeliveryInstruction, aSeamlessAuthMessagingOptionswith transports, overrides and handlers) and it all still type-checks.@seamless-auth/types/role/matchingat runtime; there is no root import anywhere indist, so neitherzodnor the schema barrel enters the module graph. Cold import of core is unchanged.That distinction is the rule worth keeping: types can come from the package root freely because they vanish at build time, but runtime values need the zod-free entry point, which is why fells-code/seamless-auth-types#7 existed.
Checks
pnpm buildclean.pnpm testpasses: 361 tests across the three packages.