feat(server): support config ThrowableError#311
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
WalkthroughThis pull request introduces a new documentation item and page for “No Throw Literal” while updating the navigation sidebar in VitePress. Numerous TypeScript types across client, server, contract, and shared packages are modified to remove strict error constraints and use the new error type, Changes
Sequence Diagram(s)sequenceDiagram
participant C as Client
participant S as safe()
participant P as Promise
C->>S: Invoke safe(clientRequest)
S->>P: Execute underlying promise
alt Promise fulfills
P-->>S: Return data
S-->>C: Return tuple [null, data, success: true]
else Promise rejects
P-->>S: Return error
S-->>C: Return tuple [error, undefined, success: false]
end
Possibly related PRs
Poem
✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
More templates
@orpc/arktype
@orpc/client
@orpc/openapi
@orpc/openapi-client
@orpc/contract
@orpc/react
@orpc/react-query
@orpc/server
@orpc/shared
@orpc/solid-query
@orpc/standard-server
@orpc/standard-server-fetch
@orpc/standard-server-node
@orpc/svelte-query
@orpc/valibot
@orpc/vue-colada
@orpc/vue-query
@orpc/zod
commit: |
dinwwwh
changed the title
ThrowableErrorThrowableError
Codecov ReportAll modified and coverable lines are covered by tests ✅ 📢 Thoughts on this report? Let us know! |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
packages/shared/src/types.ts (1)
7-14: Consider using a type alias instead of an empty interfaceThe
Registryinterface is currently empty but serves as a placeholder for configuration. Static analysis suggests using a type alias instead of an empty interface./** * The place where you can config the orpc types. * * - `throwableError` the error type that represent throwable errors should be `Error` or `null | undefined | {}` if you want more strict. */ -export interface Registry { - -} +export type Registry = { + throwableError?: unknown; +}This change would provide better type inference and eliminate the linting warning while still allowing for the same extensibility.
🧰 Tools
🪛 Biome (1.9.4)
[error] 12-14: An empty interface is equivalent to {}.
Safe fix: Use a type alias instead.
(lint/suspicious/noEmptyInterface)
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (33)
apps/content/.vitepress/config.ts(1 hunks)apps/content/docs/best-practices/no-throw-literal.md(1 hunks)packages/client/src/adapters/standard/link.ts(2 hunks)packages/client/src/index.ts(1 hunks)packages/client/src/types.ts(1 hunks)packages/client/src/utils.test-d.ts(3 hunks)packages/client/src/utils.test.ts(1 hunks)packages/client/src/utils.ts(1 hunks)packages/contract/src/error.ts(2 hunks)packages/contract/src/index.ts(1 hunks)packages/react-query/src/procedure-utils.ts(2 hunks)packages/react-query/src/types.ts(1 hunks)packages/react/src/hooks/action-hooks.ts(4 hunks)packages/server/src/adapters/fetch/handler.ts(2 hunks)packages/server/src/adapters/node/handler.ts(2 hunks)packages/server/src/adapters/standard/handler.ts(2 hunks)packages/server/src/index.ts(1 hunks)packages/server/src/procedure-action.ts(2 hunks)packages/server/src/procedure-client.test.ts(0 hunks)packages/server/src/procedure-client.ts(2 hunks)packages/shared/src/error.test.ts(0 hunks)packages/shared/src/error.ts(0 hunks)packages/shared/src/index.ts(0 hunks)packages/shared/src/interceptor.ts(3 hunks)packages/shared/src/types.ts(1 hunks)packages/solid-query/src/procedure-utils.ts(2 hunks)packages/solid-query/src/types.ts(1 hunks)packages/svelte-query/src/procedure-utils.ts(2 hunks)packages/svelte-query/src/types.ts(1 hunks)packages/vue-colada/src/procedure-utils.ts(2 hunks)packages/vue-colada/src/types.ts(1 hunks)packages/vue-query/src/procedure-utils.ts(2 hunks)packages/vue-query/src/types.ts(2 hunks)
💤 Files with no reviewable changes (4)
- packages/shared/src/index.ts
- packages/shared/src/error.ts
- packages/shared/src/error.test.ts
- packages/server/src/procedure-client.test.ts
🧰 Additional context used
🧬 Code Definitions (15)
packages/server/src/adapters/node/handler.ts (1)
packages/shared/src/types.ts (1)
ThrowableError(16-16)
packages/vue-colada/src/procedure-utils.ts (4)
packages/react-query/src/procedure-utils.ts (2)
ProcedureUtils(7-23)createProcedureUtils(29-62)packages/vue-query/src/procedure-utils.ts (2)
ProcedureUtils(9-25)createProcedureUtils(31-66)packages/client/src/types.ts (1)
ClientContext(6-6)packages/client/tests/helpers.ts (1)
ClientContext(130-130)
packages/solid-query/src/procedure-utils.ts (4)
packages/vue-colada/src/procedure-utils.ts (1)
ProcedureUtils(8-22)packages/react-query/src/procedure-utils.ts (1)
ProcedureUtils(7-23)packages/svelte-query/src/procedure-utils.ts (1)
ProcedureUtils(7-23)packages/vue-query/src/procedure-utils.ts (1)
ProcedureUtils(9-25)
packages/server/src/adapters/fetch/handler.ts (1)
packages/shared/src/types.ts (1)
ThrowableError(16-16)
packages/client/src/types.ts (2)
packages/shared/src/types.ts (1)
PromiseWithError(5-5)packages/client/tests/helpers.ts (1)
ClientContext(130-130)
packages/react-query/src/procedure-utils.ts (5)
packages/vue-query/src/procedure-utils.ts (2)
ProcedureUtils(9-25)createProcedureUtils(31-66)packages/vue-colada/src/procedure-utils.ts (2)
ProcedureUtils(8-22)createProcedureUtils(28-51)packages/solid-query/src/procedure-utils.ts (2)
ProcedureUtils(7-23)createProcedureUtils(29-62)packages/client/src/types.ts (1)
ClientContext(6-6)packages/client/tests/helpers.ts (1)
ClientContext(130-130)
packages/client/src/adapters/standard/link.ts (3)
packages/client/src/types.ts (1)
ClientOptions(30-32)packages/shared/src/types.ts (1)
ThrowableError(16-16)packages/standard-server/src/types.ts (2)
StandardRequest(13-24)StandardLazyResponse(43-49)
packages/solid-query/src/types.ts (4)
packages/vue-colada/src/types.ts (3)
QueryOptionsIn(8-11)MutationOptionsIn(15-17)MutationOptions(19-19)packages/react-query/src/types.ts (6)
QueryOptionsIn(5-8)QueryOptionsBase(10-14)InfiniteOptionsIn(16-19)InfiniteOptionsBase(21-25)MutationOptionsIn(27-29)MutationOptions(31-31)packages/svelte-query/src/types.ts (6)
QueryOptionsIn(11-14)QueryOptionsBase(16-20)InfiniteOptionsIn(22-25)InfiniteOptionsBase(27-31)MutationOptionsIn(33-35)MutationOptions(37-37)packages/vue-query/src/types.ts (6)
QueryOptionsIn(18-29)QueryOptionsBase(31-35)InfiniteOptionsIn(37-40)InfiniteOptionsBase(42-46)MutationOptionsIn(48-50)MutationOptions(52-57)
packages/client/src/utils.ts (5)
packages/contract/src/index.ts (2)
ORPCError(17-17)ThrowableError(18-18)packages/server/src/index.ts (4)
ORPCError(23-23)safe(23-23)ThrowableError(40-40)isDefinedError(23-23)packages/shared/src/types.ts (1)
ThrowableError(16-16)packages/client/src/index.ts (1)
ThrowableError(9-9)packages/client/src/types.ts (1)
ClientPromiseResult(18-18)
packages/client/src/utils.test.ts (1)
packages/client/src/utils.ts (1)
safe(14-37)
packages/vue-query/src/types.ts (4)
packages/react-query/src/types.ts (6)
QueryOptionsIn(5-8)QueryOptionsBase(10-14)InfiniteOptionsIn(16-19)InfiniteOptionsBase(21-25)MutationOptionsIn(27-29)MutationOptions(31-31)packages/client/src/types.ts (1)
ClientContext(6-6)packages/client/tests/helpers.ts (1)
ClientContext(130-130)packages/shared/src/types.ts (1)
SetOptional(1-1)
packages/react-query/src/types.ts (3)
packages/client/src/types.ts (1)
ClientContext(6-6)packages/client/tests/helpers.ts (1)
ClientContext(130-130)packages/shared/src/types.ts (1)
SetOptional(1-1)
packages/react/src/hooks/action-hooks.ts (1)
packages/shared/src/interceptor.ts (1)
Interceptor(14-18)
packages/svelte-query/src/types.ts (4)
packages/react-query/src/types.ts (6)
QueryOptionsIn(5-8)QueryOptionsBase(10-14)InfiniteOptionsIn(16-19)InfiniteOptionsBase(21-25)MutationOptionsIn(27-29)MutationOptions(31-31)packages/solid-query/src/types.ts (6)
QueryOptionsIn(11-14)QueryOptionsBase(16-20)InfiniteOptionsIn(22-25)InfiniteOptionsBase(27-31)MutationOptionsIn(33-35)MutationOptions(37-37)packages/vue-colada/src/types.ts (3)
QueryOptionsIn(8-11)MutationOptionsIn(15-17)MutationOptions(19-19)packages/vue-query/src/types.ts (6)
QueryOptionsIn(18-29)QueryOptionsBase(31-35)InfiniteOptionsIn(37-40)InfiniteOptionsBase(42-46)MutationOptionsIn(48-50)MutationOptions(52-57)
packages/vue-colada/src/types.ts (6)
packages/react-query/src/types.ts (3)
QueryOptionsIn(5-8)MutationOptionsIn(27-29)MutationOptions(31-31)packages/vue-query/src/types.ts (3)
QueryOptionsIn(18-29)MutationOptionsIn(48-50)MutationOptions(52-57)packages/solid-query/src/types.ts (3)
QueryOptionsIn(11-14)MutationOptionsIn(33-35)MutationOptions(37-37)packages/svelte-query/src/types.ts (3)
QueryOptionsIn(11-14)MutationOptionsIn(33-35)MutationOptions(37-37)packages/client/src/types.ts (1)
ClientContext(6-6)packages/client/tests/helpers.ts (1)
ClientContext(130-130)
🪛 Biome (1.9.4)
packages/shared/src/types.ts
[error] 12-14: An empty interface is equivalent to {}.
Safe fix: Use a type alias instead.
(lint/suspicious/noEmptyInterface)
🔇 Additional comments (83)
packages/server/src/procedure-client.ts (1)
8-8: Simplified error handling approachThe removal of the
toErrorimport and direct re-throwing of the original error is a good simplification. This change aligns with the PR objective of supporting more flexible error types, particularly allowing for throwable errors that may not extend theErrorclass.This approach preserves the original error object without transformation, which should provide better error fidelity and debugging information.
Also applies to: 111-113
packages/react/src/hooks/action-hooks.ts (1)
7-7: Improved type flexibility for error handlingRemoving the implicit
extends Errorconstraint from theTErrorgeneric parameter in these interfaces allows for more flexible error handling. This is consistent with the PR's objective to supportThrowableErrortypes.This change enables the interfaces to work with any type of error that might be thrown, not just those extending the JavaScript
Errorclass, which better reflects JavaScript's behavior where any value can be thrown.Also applies to: 11-11, 14-17, 19-22, 24-34, 36-46, 48-58, 60-70
packages/client/src/index.ts (1)
9-9: Added ThrowableError type exportExporting the
RegistryandThrowableErrortypes from the client package makes them available to consumers, allowing for integration with the new configurable error handling capabilities.This is a necessary addition to support the PR's objective of providing more flexible error handling options.
packages/contract/src/index.ts (1)
18-18: Exposed ThrowableError type for contract packageExporting the
RegistryandThrowableErrortypes from the contract package ensures consistent access to these types across the framework.This change appropriately complements the exports from the client package, maintaining type consistency throughout the oRPC ecosystem.
packages/server/src/index.ts (1)
40-40: Expanded type exports enhance error handling capabilitiesThe addition of
RegistryandThrowableErrortype exports from@orpc/sharedenables configurable error handling as described in the PR objectives. This change allows for more strict error type definitions in the application.apps/content/.vitepress/config.ts (1)
144-144: Documentation addition enhances best practices documentationAdding the "No Throw Literal" page to the sidebar is a nice complement to the new
ThrowableErrortype functionality, helping users understand best practices for error handling in JavaScript/TypeScript.packages/shared/src/types.ts (1)
16-16: Well-designed conditional type for flexible error handlingThe
ThrowableErrortype elegantly handles the default case (using built-inError) while allowing customization through theRegistryinterface. This implementation aligns perfectly with the PR objectives of supporting configurable throwable error types.packages/contract/src/error.ts (2)
2-2: Import of new error type enhances error handling flexibilityAdding the import for
ThrowableErroris necessary for the updated error handling system.
44-44:Details
✅ Verification successful
Updated error type improves type safety
Replacing
ErrorwithThrowableErrorin theErrorFromErrorMaptype enhances type safety by allowing users to define stricter error types. This maintains backward compatibility sinceThrowableErrordefaults toErrorwhen not configured.Let's verify that all places where
ErrorFromErrorMapis used can handle the updated type:
🏁 Script executed:
#!/bin/bash # Search for all usages of ErrorFromErrorMap to ensure they work with the updated type rg "ErrorFromErrorMap" --type ts -A 5 -B 5Length of output: 77256
Action: Verified Type Update for Enhanced Type Safety
The grep output confirms that the new definition of
export type ErrorFromErrorMap<TErrorMap extends ErrorMap> = ORPCErrorFromErrorMap<TErrorMap> | ThrowableErroris used throughout the codebase—including in tests across Vue, React, Svelte, Solid, and server implementations—with all type assertions and callbacks correctly handling the union type. The update to use
ThrowableError(which defaults toErrorwhen not configured) maintains backward compatibility while enhancing type safety.No additional modifications are needed in the usages of
ErrorFromErrorMap.packages/client/src/utils.test-d.ts (5)
10-10: New success flag added to safe function resultThe destructuring now includes a
successflag from the safe function's result, which aligns with the ThrowableError feature. This allows more nuanced error handling by explicitly indicating operation success status.
12-12: Updated error handling conditionError handling now checks both
errorpresence ANDsuccessstatus withif (error || !success), which provides more robust error detection, especially when dealing with non-Error throwable values.
36-36: Consistent success flag in object destructuring styleThe object-style destructuring has been updated to include the same
successflag as the tuple style, maintaining consistency between both usage patterns.
38-38: Consistent condition update in object styleThe same condition enhancement (
error || !success) has been applied to the object-style error handling, ensuring consistent behavior between both usage patterns.
61-66: New test case for Promise handlingThis additional test case verifies that the
safefunction properly handles Promise inputs, ensuring type safety is maintained when working with asynchronous operations. This is a valuable addition that increases test coverage for different usage scenarios.apps/content/docs/best-practices/no-throw-literal.md (5)
1-18: Well-structured documentation on throwing Error instancesThis section provides clear guidance on the best practice of throwing Error instances rather than literals in JavaScript, with good examples illustrating both incorrect and correct approaches. The info box effectively explains oRPC's default behavior.
20-30: Clear configuration instructionsThe documentation clearly explains how to customize oRPC's behavior by setting the
throwableErrorproperty in the Registry interface, with a helpful code example showing the declaration syntax. This makes it easy for developers to implement the new feature.
32-34: Important type considerations highlightedThis info box effectively warns against using overly permissive types like
anyorunknownforthrowableError, and suggests better alternatives. This helps users avoid common pitfalls that would prevent proper type inference.
36-52: Practical usage example with updated error handlingThe code example demonstrates how to properly check the
successproperty whenthrowableErroris configured, which aligns perfectly with the code changes seen in the test files. This provides valuable real-world guidance for users implementing the feature.
55-57: Helpful ESLint recommendationThe suggestion to use the ESLint
no-throw-literalrule provides users with a practical way to enforce the best practice in their codebase, adding value beyond just explaining the concept.packages/server/src/adapters/node/handler.ts (2)
1-1: Updated imports to include ThrowableErrorThe import statement now includes
ThrowableErrorfrom@orpc/shared, which is necessary for the type changes in the file.
22-22: Enhanced type safety in adapterInterceptorsThe type of
adapterInterceptorsnow usesThrowableErrorinstead ofunknown, which provides more specific typing for error handling. This change aligns with the overall PR objective of improving error type handling.This change ensures that interceptors now work with the configurable error type from the Registry, making the error handling more consistent across the codebase.
packages/vue-colada/src/procedure-utils.ts (2)
8-8: Removed Error constraint from TError type parameterThe constraint
extends Errorhas been removed from theTErrorgeneric parameter in theProcedureUtilsinterface. This allowsTErrorto be any type, not just Error instances, which is consistent with the new ThrowableError configuration feature.
28-28: Consistent removal of Error constraint in createProcedureUtilsThe same constraint removal has been applied to the
createProcedureUtilsfunction signature, ensuring consistency with the interface definition. This allows the function to work with the configurable error types as specified in the Registry.packages/vue-query/src/procedure-utils.ts (2)
9-9: Improved error type flexibilityThe constraint
extends Errorhas been removed from theTErrortype parameter, allowingProcedureUtilsto work with any error type instead of strictly Error instances. This aligns with JavaScript's ability to throw any value and the PR's objective to support a configurableThrowableErrortype.
31-31: Consistent error type handlingRemoving the
extends Errorconstraint from the function signature matches the interface change above, ensuring consistent error type handling throughout the codebase. This change maintains API compatibility while allowing more flexible error types.packages/react-query/src/procedure-utils.ts (2)
7-7: Improved error type flexibilityThe constraint
extends Errorhas been removed from theTErrortype parameter, allowingProcedureUtilsto work with any error type. This change is consistent with similar modifications in other query packages and supports the PR's objective of more flexible error handling.
29-29: Consistent error type handlingRemoving the
extends Errorconstraint from the function signature maintains consistency with the interface definition above. This change provides more flexibility in error types while preserving API compatibility.packages/solid-query/src/procedure-utils.ts (2)
7-7: Improved error type flexibilityThe constraint
extends Errorhas been removed from theTErrortype parameter, allowing any error type to be used. This change matches similar modifications in the react-query and vue-query packages, ensuring consistent error handling across all query integrations.
29-29: Consistent error type handlingRemoving the
extends Errorconstraint from the function signature complements the interface change and maintains consistency across the codebase. This modification supports the PR's goal of providing more flexible error handling.packages/server/src/adapters/fetch/handler.ts (3)
1-1: Added ThrowableError importThe import statement now includes
ThrowableErrorfrom@orpc/shared, which is used to specify a more precise error type for interceptors. This is in line with the PR's objective to provide configurable error handling.
5-5: Optimized importsThe
MaybeOptionalOptionshas been moved to a type-only import in line 1, which is good practice when you only need the type definition and not the runtime value.
21-21:Details
✅ Verification successful
Enhanced type safety with ThrowableError
The interceptor error type has been changed from generic
unknownto the more specificThrowableError. This improves type safety while maintaining flexibility, asThrowableErrorcan be customized through the Registry or default to standard Error.
🏁 Script executed:
#!/bin/bash # Check if ThrowableError is used consistently across interceptors rg -A 2 -B 2 "Interceptor<.*?,.*?,\s*\w+\s*>" --type=tsLength of output: 3716
Enhanced Type Safety via ThrowableError Verified
The interceptor error type change from a generic
unknownto the more specificThrowableErrorinpackages/server/src/adapters/fetch/handler.tshas been confirmed. This update is consistent with similar changes across the codebase (e.g., in the Node, Standard, and Client adapter files) and enhances type safety while preserving flexibility via customizable error handling.packages/client/src/types.ts (2)
18-18: Updated error type constraints to support ThrowableError featureThe
ClientPromiseResulttype now allows for any error type, not just those extendingError. This change aligns with the PR objective of supporting configurable throwable errors in JavaScript, where any value can be thrown.
20-20: Relaxed error type constraints in Client interfaceSimilarly, the
Clientinterface no longer requiresTErrorto extendError. This is consistent with theClientPromiseResulttype change and enables more flexible error handling across the codebase.packages/shared/src/interceptor.ts (3)
2-2: Added ThrowableError importAdded import for
ThrowableErrorfrom './types' to support the enhanced error handling features in interceptors.
50-50: Updated onError callback error parameter typeThe error parameter type in the
onErrorcallback has been updated to useThrowableErrorinstead of an unknown type when the return type doesn't extendPromiseWithError. This provides more specific typing and ensures consistency with the new error handling approach.
75-75: Enhanced error typing in onFinish stateThe error type in the
OnFinishStatetuple for theonFinishfunction has been updated to useThrowableErrorinstead of an unknown type. This change is consistent with the modifications inonErrorand supports the more flexible error handling system.packages/client/src/utils.test.ts (4)
6-7: Updated test expectations for successful safe callThe test expectations have been updated to include a new
success: trueflag in both the array and object results from thesafefunction. This enhancement provides clearer semantics about operation outcomes.
11-12: Updated test expectations for standard error caseTest expectations for a standard error case (non-ORPCError) now include a
success: falseflag, making error state explicit rather than implicit.
16-17: Updated test expectations for defined ORPCError caseTest expectations for a defined ORPCError now include a
success: falseflag, consistent with the error handling updates throughout the library.
21-22: Updated test expectations for undefined ORPCError caseTest expectations for an undefined ORPCError case now include a
success: falseflag, completing the consistent updates to the safe function's return value structure.packages/svelte-query/src/procedure-utils.ts (2)
7-7: Removed Error constraint from ProcedureUtils interfaceRemoved the constraint that
TErrormust extendErrorin theProcedureUtilsinterface. This aligns with the PR's objective to support more flexible error typing and is consistent with changes across the codebase.
29-29: Removed Error constraint from createProcedureUtils functionRemoved the constraint that
TErrormust extendErrorin thecreateProcedureUtilsfunction signature. This change complements the interface update and maintains consistency in the error handling approach.packages/server/src/procedure-action.ts (4)
3-3: Well-structured import for ThrowableErrorThe import of
ThrowableErrorfrom the shared package aligns with the PR objective of supporting configurable throwable errors.
6-6: Good enhancement of ActionableError type flexibilityRemoving the
extends Errorconstraint allows for more flexible error handling, aligning with the PR's goal of supporting diverse error types that JavaScript can throw.
8-8: Improved type safety with ThrowableErrorChanging the fallback type from
ErrortoThrowableErrorprovides more accurate typing for unactionable errors. This is consistent with the PR's objective of providing more strict error types.
30-30: Enhanced flexibility for createActionableClientRemoving the
extends Errorconstraint from theTErrortype parameter allows the function to handle any thrown value, consistent with the changes to the type definitions above.packages/client/src/utils.ts (4)
1-1: Added import for ThrowableErrorImporting
ThrowableErrorfrom the shared package is appropriate for its usage in the updatedsafefunction signature.
6-12: Enhanced SafeResult type with success flagAdding a
successboolean property to theSafeResulttype improves the API usability by providing a clear indicator of operation outcome. This is a good enhancement that allows consumers to check success state directly rather than having to check multiple properties.
14-14: Improved flexibility with ThrowableError defaultSetting
ThrowableErroras the default type forTErroraligns with the PR's objective while maintaining backward compatibility. This change makes the function more flexible for handling various error types.
18-19: Consistent implementation of success flagThe implementation consistently sets the
successproperty in all return scenarios, ensuring the type and runtime behavior are aligned. The use ofsatisfieskeyword provides additional type safety for the returned tuples.Also applies to: 27-28, 33-34
packages/client/src/adapters/standard/link.ts (2)
1-1: Appropriate import for ThrowableErrorAdding
ThrowableErrorto the imports from@orpc/sharedprepares for its usage in the interceptor types.
14-15: Enhanced type safety for interceptorsReplacing
unknownwithThrowableErrorfor the interceptor error types improves type safety and aligns with the PR's objective of providing more strict error types. This change ensures that error handling is more predictable across the standard link adapter.packages/server/src/adapters/standard/handler.ts (2)
3-3: Added ThrowableError to importsIncluding
ThrowableErrorin the imports from@orpc/sharedprepares for its usage in the handler interceptor types.
34-34: Improved type safety for handler interceptorsChanging both
interceptorsandrootInterceptorserror types fromunknowntoThrowableErrorbrings better type safety to the server-side error handling. This change is consistent with the client-side changes and aligns with the PR's objective of providing more strict error types throughout the framework.Also applies to: 39-39
packages/solid-query/src/types.ts (6)
11-14: Type constraint removal for QueryOptionsIn TError parameterThe removal of the
extends Errorconstraint from theTErrortype parameter inQueryOptionsInallows for more flexible error handling. This change supports the newThrowableErrorconfiguration option, permitting any type to be used for errors instead of restricting to Error subclasses.
16-20: Type constraint removal for QueryOptionsBase TError parameterThe
extends Errorconstraint has been removed from theTErrorparameter in theQueryOptionsBaseinterface. This modification is consistent with the overall PR objective to allow for more flexible error type handling.
22-25: Type constraint removal for InfiniteOptionsIn TError parameterThe
TErrorparameter no longer requires extending the Error class, aligning with the rest of the changes to support the newThrowableErrorconfiguration option.
27-31: Type constraint removal for InfiniteOptionsBase TError parameterRemoval of the
extends Errorconstraint from theTErrorparameter inInfiniteOptionsBaseinterface continues the pattern of allowing more flexible error types.
33-35: Type constraint removal for MutationOptionsIn TError parameterThe
TErrortype parameter inMutationOptionsInis no longer constrained to extend Error, consistent with the other type changes in this PR.
37-37: Type constraint removal for MutationOptions TError parameterThe
extends Errorconstraint has been removed from theTErrorparameter in theMutationOptionstype, completing the consistent pattern of changes across all query and mutation types.packages/svelte-query/src/types.ts (6)
11-14: Type constraint removal for QueryOptionsIn TError parameterThe removal of the
extends Errorconstraint from theTErrorparameter inQueryOptionsInallows for more flexible error handling in Svelte query operations, consistent with the changes in other packages.
16-20: Type constraint removal for QueryOptionsBase TError parameterThe
extends Errorconstraint has been removed from theTErrorparameter in theQueryOptionsBaseinterface, matching the pattern established in the solid-query package.
22-25: Type constraint removal for InfiniteOptionsIn TError parameterThe
TErrorparameter inInfiniteOptionsInno longer requires extending the Error class, consistently applying the new error handling approach across packages.
27-31: Type constraint removal for InfiniteOptionsBase TError parameterRemoval of the
extends Errorconstraint from theTErrorparameter in theInfiniteOptionsBaseinterface continues the pattern of allowing more flexible error types.
33-35: Type constraint removal for MutationOptionsIn TError parameterThe
TErrortype parameter inMutationOptionsInis no longer constrained to extend Error, aligning with the changes in other types.
37-37: Type constraint removal for MutationOptions TError parameterThe
extends Errorconstraint has been removed from theTErrorparameter in theMutationOptionstype, completing the consistent pattern across all Svelte query types.packages/vue-query/src/types.ts (6)
18-29: Type constraint removal for QueryOptionsIn TError parameterThe
extends Errorconstraint has been removed from theTErrorparameter in theQueryOptionsIntype for Vue query operations. This change is more extensive than in other packages due to the complex type structure that includes MaybeRefDeep and QueryObserverOptions integrations. The change maintains consistency with other packages while preserving Vue's reactive typing.
31-35: Type constraint removal for QueryOptionsBase TError parameterThe
extends Errorconstraint has been removed from theTErrorparameter in theQueryOptionsBaseinterface, continuing the pattern established across packages.
37-40: Type constraint removal for InfiniteOptionsIn TError parameterThe
TErrorparameter inInfiniteOptionsInno longer requires extending the Error class, consistently applying the new error handling approach for infinite queries in Vue.
42-46: Type constraint removal for InfiniteOptionsBase TError parameterRemoval of the
extends Errorconstraint from theTErrorparameter inInfiniteOptionsBaseinterface maintains consistency with other types and packages.
48-50: Type constraint removal for MutationOptionsIn TError parameterThe
TErrortype parameter inMutationOptionsInis no longer constrained to extend Error, aligning with the changes in query types.
52-57: Type constraint removal for MutationOptions TError parameterThe
extends Errorconstraint has been removed from theTErrorparameter in theMutationOptionstype. This change maintains the Vue-specific implementation with MaybeRefDeep wrappers while allowing for more flexible error typing.packages/vue-colada/src/types.ts (4)
8-11: Type constraint removal for QueryOptionsIn TError parameterThe
extends Errorconstraint has been removed from theTErrorparameter in theQueryOptionsIntype for Vue Colada, adapting this integration package to support the new flexible error handling approach.
13-13: Type constraint removal for QueryOptions TError parameterThe
extends Errorconstraint has been removed from theTErrorparameter in theQueryOptionstype, which is unique to the vue-colada package and necessary for its integration with Pinia.
15-17: Type constraint removal for MutationOptionsIn TError parameterThe
TErrortype parameter inMutationOptionsInis no longer constrained to extend Error, maintaining consistency with the query types.
19-19: Type constraint removal for MutationOptions TError parameterThe
extends Errorconstraint has been removed from theTErrorparameter in theMutationOptionstype, completing the consistent pattern of changes across all Vue Colada types.packages/react-query/src/types.ts (6)
5-5: Improved flexibility in error handling for QueryOptionsIn.Removing the
extends Errorconstraint from theTErrorgeneric parameter allows for more versatile error types beyond standard Error objects. This aligns with the PR's objective to support configurable throwable errors.
10-10: Consistent error type flexibility in QueryOptionsBase.The removal of
extends Errorconstraint here maintains consistency with other type definitions, allowing for a unified approach to error typing throughout the system.
16-16: Enhanced error typing for infinite queries.Removing the Error constraint for
TErrorin InfiniteOptionsIn enables support for custom error types in infinite query scenarios, maintaining feature parity with standard queries.
21-21: Consistent error flexibility in InfiniteOptionsBase.This change aligns with the broader pattern of removing Error type constraints across the codebase, ensuring consistent behavior for error handling.
27-27: Extended error support for mutations.Removing the Error constraint for
TErrorin MutationOptionsIn provides consistent error handling capabilities between queries and mutations, which is especially important for symmetric API design.
31-31: Broadened error typing for base mutation options.This change completes the pattern of error type flexibility throughout the React Query integration, ensuring a cohesive approach to error handling across all operation types.
1 participant
This allow config throwable-error this can helpful when you want more strict error types - js allow throw any value but by default oRPC treat you throw an Error instance, it's a best practice and fine in 99.5% cases
Summary by CodeRabbit
Documentation
New Features
Refactor