Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
WalkthroughThis pull request refactors numerous import statements across multiple packages and files. The changes primarily separate type-only imports from runtime imports, update formatting (e.g., spacing in generator functions and type assertions), and remove or update ESLint configurations and React-related dependencies in package settings. Additionally, a minor update in React hook usage replaces Changes
Sequence Diagram(s)sequenceDiagram
participant C as React Component
participant H as useORPC Hook
participant O as ORPCContext Provider
C->>H: call useORPC()
H->>O: invoke use(ORPCContext)
alt Context exists
O-->>H: return ORPC context
H-->>C: return ORPCReactUtils
else Context missing
O-->>H: return undefined
H-->>C: throw error "ORPC context not defined"
end
Possibly related PRs
Poem
Tip ⚡💬 Agentic Chat (Pro Plan, General Availability)
✨ 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 (
|
Codecov ReportAll modified and coverable lines are covered by tests ✅ 📢 Thoughts on this report? Let us know! |
More templates
@orpc/arktype
@orpc/client
@orpc/openapi
@orpc/contract
@orpc/openapi-client
@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: |
![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 (2)
packages/contract/src/event-iterator.test.ts (2)
56-58: Intentional Use of Return-Only Async GeneratorThe async generator function in the "can validate returns" test (lines 56–58) does not use a
yieldstatement and only returns a value. Although static analysis warns with “This generator function doesn't contain yield,” this is an intentional design to test return-only behavior of async generators.
If this pattern is deliberate, consider adding an inline ESLint disable comment (e.g.// eslint-disable-next-line lint/correctness/useYield) to suppress the warning and document the intent.🧰 Tools
🪛 Biome (1.9.4)
[error] 56-58: This generator function doesn't contain yield.
(lint/correctness/useYield)
76-78: False Positive from Static Analysis on Async GeneratorSimilarly, the async generator in the "not required returns schema" test (lines 76–78) omits a yield and directly returns a value. This design choice is intentional for testing and triggers a static analysis warning.
A brief inline ESLint disable comment here would clarify that the absence of yield is expected and avoid confusion from automated tools.🧰 Tools
🪛 Biome (1.9.4)
[error] 76-78: This generator function doesn't contain yield.
(lint/correctness/useYield)
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (67)
apps/content/docs/advanced/validation-errors.md(3 hunks)apps/content/docs/tanstack-query/react.md(2 hunks)apps/content/examples/openai-streaming.md(1 hunks)eslint.config.js(0 hunks)package.json(1 hunks)packages/client/src/adapters/standard/link.ts(1 hunks)packages/client/src/adapters/standard/rpc-json-serializer.ts(1 hunks)packages/client/src/adapters/standard/rpc-link-codec.ts(1 hunks)packages/client/src/adapters/standard/rpc-link.ts(1 hunks)packages/client/src/dynamic-link.test-d.ts(1 hunks)packages/client/src/error.ts(2 hunks)packages/client/src/plugins/batch.test.ts(1 hunks)packages/client/src/plugins/simple-csrf-protection.ts(1 hunks)packages/client/src/utils.test-d.ts(1 hunks)packages/contract/src/builder-variants.test-d.ts(1 hunks)packages/contract/src/builder.ts(1 hunks)packages/contract/src/event-iterator.test.ts(3 hunks)packages/contract/src/router-utils.ts(1 hunks)packages/contract/src/schema.test-d.ts(1 hunks)packages/openapi-client/src/adapters/fetch/openapi-link.ts(1 hunks)packages/openapi-client/src/adapters/standard/bracket-notation.ts(1 hunks)packages/openapi-client/src/adapters/standard/openapi-link-codec.ts(1 hunks)packages/openapi-client/src/adapters/standard/openapi-link.ts(1 hunks)packages/openapi/src/adapters/node/openapi-handler.ts(1 hunks)packages/openapi/src/adapters/standard/openapi-handler.ts(1 hunks)packages/openapi/src/adapters/standard/openapi-matcher.ts(1 hunks)packages/openapi/src/openapi-generator.test.ts(1 hunks)packages/openapi/src/openapi-generator.ts(2 hunks)packages/react-query/src/router-utils.ts(1 hunks)packages/react/src/hooks/action-hooks.ts(1 hunks)packages/server/src/adapters/fetch/handler.ts(1 hunks)packages/server/src/adapters/fetch/plugin.ts(1 hunks)packages/server/src/adapters/fetch/rpc-handler.ts(1 hunks)packages/server/src/adapters/node/handler.ts(1 hunks)packages/server/src/adapters/node/rpc-handler.ts(1 hunks)packages/server/src/adapters/standard/handler.ts(1 hunks)packages/server/src/adapters/standard/plugin.test.ts(1 hunks)packages/server/src/adapters/standard/rpc-handler.ts(1 hunks)packages/server/src/builder-variants.test-d.ts(2 hunks)packages/server/src/builder.ts(1 hunks)packages/server/src/implementer-procedure.ts(1 hunks)packages/server/src/implementer-variants.test-d.ts(1 hunks)packages/server/src/implementer.test-d.ts(1 hunks)packages/server/src/implementer.ts(2 hunks)packages/server/src/plugins/cors.ts(1 hunks)packages/server/src/plugins/simple-csrf-protection.ts(1 hunks)packages/server/src/procedure-client.test-d.ts(1 hunks)packages/server/src/procedure-client.ts(1 hunks)packages/server/src/procedure-utils.ts(1 hunks)packages/server/src/router-utils.ts(1 hunks)packages/shared/src/value.test-d.ts(1 hunks)packages/solid-query/src/router-utils.ts(1 hunks)packages/standard-server-fetch/src/body.ts(1 hunks)packages/standard-server-fetch/src/event-iterator.test.ts(1 hunks)packages/standard-server-node/src/body.ts(1 hunks)packages/standard-server-node/src/event-iterator.test.ts(1 hunks)packages/standard-server/src/batch/response.test.ts(1 hunks)packages/svelte-query/src/router-utils.ts(1 hunks)packages/valibot/src/converter.ts(1 hunks)packages/vue-colada/src/router-utils.ts(1 hunks)packages/vue-query/src/procedure-utils.test-d.ts(1 hunks)packages/vue-query/src/router-utils.ts(1 hunks)packages/vue-query/src/utils.ts(1 hunks)packages/zod/src/coercer.test.ts(1 hunks)packages/zod/src/schemas/file.ts(1 hunks)packages/zod/src/schemas/url.ts(1 hunks)playgrounds/nextjs/src/app/orpc-query.tsx(0 hunks)
💤 Files with no reviewable changes (2)
- eslint.config.js
- playgrounds/nextjs/src/app/orpc-query.tsx
🧰 Additional context used
🧬 Code Graph Analysis (7)
packages/standard-server-fetch/src/event-iterator.test.ts (2)
packages/standard-server-fetch/src/event-iterator.ts (2)
toEventIterator(10-68)toEventStream(93-155)packages/standard-server-node/src/event-iterator.ts (2)
toEventIterator(11-69)toEventStream(94-156)
packages/server/src/implementer-procedure.ts (1)
packages/server/src/procedure-client.ts (1)
ProcedureClient(16-26)
packages/standard-server-node/src/event-iterator.test.ts (2)
packages/standard-server-fetch/src/event-iterator.ts (2)
toEventIterator(10-68)toEventStream(93-155)packages/standard-server-node/src/event-iterator.ts (2)
toEventIterator(11-69)toEventStream(94-156)
packages/server/src/implementer.test-d.ts (2)
packages/server/src/router-utils.ts (1)
EnhancedRouter(76-102)packages/server/tests/shared.ts (2)
InitialContext(7-7)CurrentContext(8-8)
packages/server/src/implementer-variants.test-d.ts (2)
packages/server/src/router-utils.ts (1)
EnhancedRouter(76-102)packages/server/tests/shared.ts (2)
InitialContext(7-7)CurrentContext(8-8)
packages/vue-query/src/procedure-utils.test-d.ts (2)
packages/contract/src/error.ts (1)
ErrorFromErrorMap(44-44)packages/contract/tests/shared.ts (1)
baseErrorMap(12-17)
packages/server/src/implementer.ts (1)
packages/server/src/context.ts (1)
Context(1-1)
🪛 Biome (1.9.4)
packages/contract/src/event-iterator.test.ts
[error] 56-58: This generator function doesn't contain yield.
(lint/correctness/useYield)
[error] 76-78: This generator function doesn't contain yield.
(lint/correctness/useYield)
🔇 Additional comments (79)
apps/content/examples/openai-streaming.md (1)
31-31: Correct Use of Yield*
The change fromyield * streamtoyield* streamcorrectly adheres to JavaScript’s syntax for delegating yield. This update ensures that the generator properly yields values from the inner iterator.packages/shared/src/value.test-d.ts (1)
1-2: Separation of Type and Value Imports
Splitting the import intoimport type { Value } from './value'andimport { value } from './value'clarifies the intended usage and avoids potential runtime overhead. This follows best practices in TypeScript.apps/content/docs/tanstack-query/react.md (1)
77-87: Adoption of React’suseHook for Context Consumption
ReplacinguseContext(ORPCContext)withuse(ORPCContext)indicates an intentional move toward the new React hook for accessing context. Please verify that your project’s React version supports this experimental hook usage and that its semantics fit your application’s requirements.apps/content/docs/advanced/validation-errors.md (3)
19-20: Proper Separation of Zod Type Import (Hunk 1)
Splitting the original import intoimport { ZodError } from 'zod'andimport type { ZodIssue } from 'zod'makes clear thatZodIssueis used solely for type checking. This enhances clarity and aligns with modern TypeScript practices.
57-58: Consistent Import Style for Zod in Middleware (Hunk 2)
The revised imports (import { z, ZodError } from 'zod'followed byimport type { ZodIssue } from 'zod') maintain consistency and reduce any ambiguity about runtime versus type-only values.
110-111: Uniform Type-Only Import for ZodIssue (Hunk 3)
The update to importZodIssueas a type-only dependency continues the established pattern, thereby keeping the codebase clean and well-organized.packages/valibot/src/converter.ts (1)
3-4: Clear Delineation Between Type and Runtime Imports
Changing the import ofConversionConfigto a type-only import and importingtoJsonSchemanormally distinguishes between compile-time and runtime needs effectively. This refactor improves clarity without impacting functionality.packages/client/src/adapters/standard/rpc-link-codec.ts (1)
1-1: Type imports are now properly separated from value imports.The reorganization of imports improves code clarity by clearly distinguishing between types and runtime values, which is a good TypeScript practice.
Also applies to: 6-6
packages/client/src/plugins/simple-csrf-protection.ts (1)
1-1: Type imports are now properly separated from value imports.This change follows the same pattern of separating type imports from runtime value imports, which helps with code organization and potentially with build optimization.
Also applies to: 4-4
packages/standard-server-fetch/src/body.ts (1)
1-1: Type imports are now properly separated from value imports.The separation of the
StandardBodytype import from the function imports is consistent with TypeScript best practices and aligns with the changes made throughout the codebase.Also applies to: 4-4
packages/svelte-query/src/router-utils.ts (1)
2-5: Import statements have been reorganized for better clarity.The imports have been clearly separated into type imports and value imports, with each import on its own line. This improves readability and is consistent with the approach taken in other files.
packages/react/src/hooks/action-hooks.ts (1)
3-5: Import refinement looks good.The changes appropriately separate type imports from runtime imports, following best practices for TypeScript. This improves code organization and clarity.
packages/openapi-client/src/adapters/standard/bracket-notation.ts (1)
1-2: Clean separation of type and value imports.Good refactoring to separate the type import from the runtime import, improving code organization without changing functionality.
packages/client/src/error.ts (2)
1-2: Type import separation looks good.Well-structured separation of type imports from runtime imports, following TypeScript best practices.
176-176: Fixed generic type formatting.The spacing around generic type parameters has been standardized, improving code consistency.
packages/openapi/src/adapters/standard/openapi-matcher.ts (1)
2-6: Clean separation of type imports.Good refactoring to separate the type import for
AnyContractProcedurefrom the runtime import offallbackContractConfig, improving code clarity and organization.packages/openapi-client/src/adapters/standard/openapi-link-codec.ts (2)
1-4: Well-structured type imports.Good refactoring to separate type imports for
ClientContext,ClientOptions,HTTPPath, andValuefrom their respective modules, improving code organization.
7-10: Clean separation of runtime imports.The runtime imports have been properly organized without mixing type imports, following TypeScript best practices.
packages/standard-server/src/batch/response.test.ts (2)
13-16: Consistent async generator formatting in batch response.The change adds a space between
function*and the opening parenthesis (i.e.async function* () {), which improves readability and enforces a consistent code style.
47-50: Uniform formatting in error scenario test.The async generator in the “throw on invalid batch item” test now follows the updated formatting rules by adding a space between
function*and(, ensuring consistency across tests.packages/client/src/plugins/batch.test.ts (2)
138-139: Async generator formatting update in unsupported body test.The change to the async generator used inside the
it.eacharray (i.e. changing from(async function*() {})()to(async function* () {})()) makes the declaration clearer and consistent with our ESLint rules.
1-137: Overall consistency check for BatchLinkPlugin tests.All formatting updates appear to be cosmetic and ensure that async generator declarations are uniformly styled throughout the file without affecting the test logic.
packages/client/src/utils.test-d.ts (1)
64-66: Refined type assertion formatting.The updated type assertion (ensuring the correct formatting of
number | undefinedwithout the extra space or symbol) improves clarity, while leaving the test logic intact.packages/standard-server-node/src/event-iterator.test.ts (2)
326-334: Consistent async generator formatting in event iterator tests.The changes—especially in the
it.eachtest case where the async generator is declared as(async function* () { for (const value of values) { yield value } })()—improve readability and ensure consistency with our ESLint formatting rules. No functional changes were introduced.
1-325: Overall formatting improvements maintain test integrity.The formatting updates applied across the file (such as adding spaces in async generator declarations) are purely stylistic. They enhance clarity without impacting the functionality or the control flow of the tests.
packages/standard-server-fetch/src/event-iterator.test.ts (2)
326-334: Uniform async generator declaration in event stream iterator test.The change to add a space between
function*and the parentheses in the async generator (inside theit.eachblock) increases code clarity and aligns with our updated ESLint rules.
1-325: Overall review of event iterator tests formatting.All modifications in this file are formatting improvements—ensuring consistent use of spacing in async generator declarations. There are no functional or logic changes, which is appropriate for a chore update such as this.
packages/client/src/dynamic-link.test-d.ts (1)
6-7: Formatting Consistency in Type AssertionThe change on line 7 removes an extra space inside the generic type and improves overall consistency in type assertions.
packages/server/src/implementer-procedure.ts (1)
73-75: Refined Return Type Formatting forcallableThe update on line 74 removes an unnecessary space in the return type’s generic usage, ensuring a cleaner and more consistent formatting. No functionality is affected.
packages/zod/src/coercer.test.ts (1)
1-2: Separation of Type-Only and Runtime ImportsThe changes on lines 1–2 correctly separate the type-only import for
ZodTypeAnyfrom the runtime import ofz. This improves clarity regarding the usage of these imports.packages/zod/src/schemas/file.ts (2)
1-2: Organized Import DeclarationsThe revised import statements on lines 1–2 now clearly designate
ZodEffects,ZodType,ZodTypeDef, andCustomParamsas type-only. This enhances readability and avoids bundling types with runtime code.
4-5: Separation of Value Imports from TypesThe adjustment on lines 4–5 separates the value import (
custom,composeParams,setCustomZodDef) from type imports. This change is consistent with the project's efforts to clearly differentiate type-only imports and is well executed.packages/vue-query/src/procedure-utils.test-d.ts (1)
119-119: Refined Generic Type AssertionThe change on line 119 cleans up the generic type usage by removing the extra space between
ErrorFromErrorMapand the<typeof baseErrorMap>expression. This enhances consistency in type assertions across the tests.packages/server/src/plugins/cors.ts (1)
1-5: Separation of Type and Value ImportsThe changes clearly separate the type-only import for
Value(line 1) from the runtime import forvalue(line 5). This improves clarity and prevents type-only constructs from being bundled into runtime code.packages/client/src/adapters/standard/rpc-link.ts (2)
2-4: Consistent Use of Type-Only Imports for OptionsThe refactoring to import
StandardLinkOptions,StandardRPCJsonSerializerOptions, andStandardRPCLinkCodecOptionsas type-only imports clarifies their intended use and aligns with ESLint’s recommendations.
6-8: Correct Separation of Runtime ImportsThe runtime imports for
StandardLink,StandardRPCJsonSerializer, andStandardRPCLinkCodec(lines 6–8) are now clearly distinguished from type-only imports. This separation benefits build optimizations and improves maintainability.packages/client/src/adapters/standard/rpc-json-serializer.ts (1)
1-2: Improved Import StructureThe updated import statements now use a type-only import for
Segment(line 1) and a separate runtime import forisObject(line 2). This modification enhances clarity and ensures that only necessary values are bundled at runtime.packages/vue-query/src/utils.ts (1)
1-3: Proper Separation of Type and Value ImportsThe changes here introduce a type-only import for
AnyFunction(line 1) while retaining the runtime import forisObject(line 3). This clear demarcation adheres to updated linting rules and improves overall code readability.packages/server/src/adapters/fetch/handler.ts (1)
1-8: Improved import organization for better type clarity.The imports have been reorganized to separate type imports from value imports, following TypeScript best practices. This enhances code clarity and potentially helps with tree-shaking.
packages/server/src/adapters/standard/plugin.test.ts (1)
1-2: Clean separation of type-only imports.The import statements have been split to clearly distinguish between type and value imports, which is a good TypeScript practice that improves code clarity.
packages/server/src/implementer.test-d.ts (1)
144-144: Improved type formatting consistency.Removed unnecessary space before the generic type parameter, following consistent TypeScript formatting conventions.
packages/server/src/procedure-client.test-d.ts (1)
7-10: Proper separation of type and value imports.Imports have been reorganized to follow the TypeScript best practice of separating type imports from value imports, improving code clarity and maintainability.
packages/server/src/implementer-variants.test-d.ts (1)
75-75: Corrected type formatting for consistency.Removed unnecessary space in generic type parameter syntax for consistent TypeScript formatting across the codebase.
packages/server/src/procedure-utils.ts (1)
5-8: Type imports are now separated following the TypeScript convention.The change appropriately separates type imports from value imports, which is a good TypeScript practice. This provides better clarity about which imports are used at compile time versus runtime.
packages/server/src/plugins/simple-csrf-protection.ts (1)
2-7: Type imports are now separated following the TypeScript convention.The change correctly separates the
Valuetype import from thevaluefunction import, making it clearer which is used at compile time versus runtime.packages/openapi/src/openapi-generator.ts (1)
6-15: Type imports are now separated following the TypeScript convention.The change properly separates type imports (
ConditionalSchemaConverter,SchemaConverter) from value imports (CompositeSchemaConverter), improving code organization and clarity.packages/server/src/adapters/fetch/rpc-handler.ts (1)
3-5: Type imports are now separated following the TypeScript convention.The change appropriately separates the
StandardRPCHandlerOptionstype import from theStandardRPCHandlerclass import, aligning with good TypeScript practices.packages/openapi/src/adapters/standard/openapi-handler.ts (1)
1-5: LGTM! Clean import reorganizationThe changes properly separate type imports from value imports, which is a TypeScript best practice. This restructuring improves code clarity without changing functionality.
packages/client/src/adapters/standard/link.ts (1)
4-7: LGTM! Better separation of type vs. value importsThe refactoring cleanly separates the type import of
StandardLinkPluginfrom the value import ofCompositeStandardLinkPlugin. This improves code organization while maintaining the same functionality.packages/react-query/src/router-utils.ts (1)
2-5: LGTM! Improved import organizationThe changes properly separate type imports from function imports, following TypeScript best practices. This restructuring makes it clearer what's used at runtime versus compile time.
packages/zod/src/schemas/url.ts (1)
2-4: LGTM! Better type import separationThe refactoring properly separates the type import (
CustomParams) from value imports (composeParams,setCustomZodDef), which follows TypeScript best practices and improves code readability.packages/server/src/adapters/fetch/plugin.ts (1)
2-2: Import organization improvement.The imports have been restructured to separate type-only imports from value imports, which aligns with modern TypeScript best practices. This change improves code organization without affecting functionality.
Also applies to: 4-4
packages/openapi/src/openapi-generator.test.ts (1)
1-1: Type imports properly separated from value imports.The import statements have been restructured to explicitly separate the type-only import (
AnyContractProcedure) from runtime imports (eventIteratorandoc). This is consistent with the ESLint update mentioned in the PR title.Also applies to: 4-4
packages/contract/src/builder.ts (1)
3-5: Improved import organization following TypeScript best practices.Imports have been restructured to separate type-only imports from value imports, creating clearer distinction between compile-time and runtime dependencies. This improves code organization and potentially helps with tree-shaking.
Also applies to: 7-8, 10-12, 14-14
packages/server/src/adapters/standard/handler.ts (1)
8-8: Type imports properly separated from value imports.The code now clearly distinguishes between type-only imports and runtime value imports. This change is consistent with the ESLint configuration update mentioned in the PR title and improves code organization.
Also applies to: 13-13
packages/server/src/router-utils.ts (1)
3-3: Improved import organization with type-only importsThe changes separate type-only imports from runtime imports, which follows TypeScript best practices for better tree-shaking and code clarity.
Also applies to: 5-5, 8-8, 10-10
packages/openapi-client/src/adapters/fetch/openapi-link.ts (2)
2-6: Reorganized imports to separate types from runtime importsThe import statements have been refactored to:
- Isolate type imports with the
typekeyword- Import runtime components separately from their types
This change improves code organization and helps with tree-shaking.
8-9: Well-structured interface extending both parent interfacesThe
OpenAPILinkOptionsinterface properly extends bothStandardOpenAPILinkOptions<T>andLinkFetchClientOptions<T>, which matches the reorganized imports.packages/openapi/src/adapters/node/openapi-handler.ts (1)
3-3: Refined imports with type-only declarationThe changes separate the type import
StandardOpenAPIHandlerOptionsfrom the class importStandardOpenAPIHandler, following TypeScript best practices for clearer code organization.Also applies to: 5-5
packages/server/src/builder.ts (1)
130-130: Fixed formatting in return type declarationRemoved extra space before the closing angle bracket for consistent type formatting.
packages/server/src/procedure-client.ts (1)
2-5: Type imports separated from value importsGood refactoring to separate type imports from value imports. This better follows TypeScript best practices and can potentially help with tree-shaking.
Also applies to: 9-12
packages/server/src/adapters/node/rpc-handler.ts (1)
3-5: Type import properly separated from value importThe split of StandardRPCHandlerOptions as a type import and StandardRPCHandler as a value import is a good refactoring practice.
packages/standard-server-node/src/body.ts (1)
1-1: Import declaration refactored correctlyGood reorganization of imports, separating type imports from value imports. This follows modern TypeScript best practices.
Also applies to: 7-7
packages/server/src/adapters/node/handler.ts (1)
5-6: Proper separation of type and value importsNice refactoring to separate type imports from value imports, which improves code organization and follows TypeScript best practices.
Also applies to: 9-10
packages/server/src/implementer.ts (2)
3-3: Import structure improved with separate type declarations.The code now follows the best practice of separating type imports from value imports. This improves clarity about which imports are only used for type-checking and won't be included in the compiled JavaScript, potentially leading to better tree-shaking.
Also applies to: 10-10, 12-12, 14-14, 17-17, 20-20
171-171: Fixed extra whitespace.Removed unnecessary space after the comma, improving formatting consistency.
packages/contract/src/builder-variants.test-d.ts (1)
2-2: Improved separation of type and value imports.Types like
baseErrorMap,BaseMeta,inputSchema, andoutputSchemaare now imported withimport typesyntax, while actual values (generalSchema,ping,pong) remain with the standard import syntax. This clearly distinguishes between compile-time and runtime dependencies.Also applies to: 9-9
packages/contract/src/router-utils.ts (1)
1-2: Enhanced import organization with type separation.Type imports have been properly separated from value imports, following TypeScript best practices. This makes the code more maintainable by clearly indicating which imports are only used for type checking.
Also applies to: 4-4, 6-6
packages/contract/src/schema.test-d.ts (1)
1-1: Clean separation of type imports from value imports.The code now properly distinguishes between type imports (
AnySchema,InferSchemaInput,InferSchemaOutput) and the value import (type). This improves code organization and helps the TypeScript compiler with optimization.Also applies to: 5-5
packages/openapi-client/src/adapters/standard/openapi-link.ts (1)
2-9: Improved import organization by separating type imports from runtime importsThe changes properly separate type imports from runtime imports, which is a TypeScript best practice. This helps with tree-shaking and makes the import structure clearer.
packages/server/src/builder-variants.test-d.ts (1)
3-4: Clean separation of type and runtime importsThe changes properly organize imports by separating type-only imports from runtime imports. This improves code readability and follows modern TypeScript best practices.
Also applies to: 14-15
packages/server/src/adapters/standard/rpc-handler.ts (1)
1-7: Well-organized import structureThe refactoring correctly separates type imports from runtime imports, which helps with code organization and potential tree-shaking optimizations.
packages/vue-query/src/router-utils.ts (1)
2-5: Clean separation of types and implementation importsThe import statements have been properly refactored to separate type imports from their implementation imports, which is aligned with modern TypeScript best practices.
packages/solid-query/src/router-utils.ts (2)
2-5: Clean Separation of Type vs. Value Imports
The updated import statements clearly separate the type-only imports (GeneralUtilsandProcedureUtils) from the function imports (createGeneralUtilsandcreateProcedureUtils). This enhances code clarity and helps ensure that type information is dropped during runtime, which can lead to potential bundle size optimizations.
7-53: Overall Structure and Functionality Preservation
No changes other than import reorganization were applied to the core logic. The implementation ofRouterUtilsandcreateRouterUtilsremains unchanged, preserving the original functionality. This consistency is good for maintainability.packages/vue-colada/src/router-utils.ts (2)
2-5: Improved Import Organization for Clarity
Similar to the solid-query version, the changes here separate type imports from value imports. This clear division aids in understanding which imports are needed only at compile time and helps avoid bundling extraneous type data at runtime.
7-53: Preservation of Core Logic
The functional parts of the module, including the type alias and thecreateRouterUtilsfunction, remain unchanged. This ensures that the behavior of the module is intact while benefiting from improved import clarity.package.json (2)
29-31: Updated @antfu/eslint-config Dependency VersionThe dependency has been upgraded to
"@antfu/eslint-config": "^4.0.0". Since this is a major version bump from the previous release, please verify that all custom ESLint configurations still function as expected without introducing breaking changes.
29-51:Details
✅ Verification successful
Review Removal of React-Specific ESLint Plugins
According to the PR objectives and enriched summary, the removal of React-specific linting plugins (e.g.,
@eslint-react/eslint-plugin,eslint-plugin-react-hooks, andeslint-plugin-react-refresh) should now be reflected in the ESLint configuration. Please ensure that no residual references to these plugins exist in other configuration files (e.g.,eslint.config.js), and that the new linting rules work correctly without them.
Let's run a shell script to search the repository for any residual references to the removed React-specific ESLint plugins (i.e.,
@eslint-react/eslint-plugin,eslint-plugin-react-hooks, andeslint-plugin-react-refresh). This will help verify that the ESLint configuration—and any other configuration files—do not unintentionally include these packages.
🏁 Script executed:
#!/bin/bash # Search the repository for any occurrences of the removed React-specific ESLint plugins. rg --ignore-case "(eslint-plugin-react-hooks|eslint-plugin-react-refresh|@eslint-react/eslint-plugin)" .Length of output: 2623
ESLint Config: Confirm Removal of React-Specific Plugins
Your changes effectively remove direct references to the React-specific ESLint plugins from configuration files. A global search confirmed that files like
eslint.config.js(as well as other ESLint config files) no longer reference@eslint-react/eslint-plugin,eslint-plugin-react-hooks, oreslint-plugin-react-refresh. The only remaining mentions appear in the lock file as nested dependencies from packages (e.g., within@antfu/eslint-config), which is expected.Please verify that the updated lint rules work correctly without these plugins, and consider whether the indirect dependencies in the lock file may impact your linting behavior or bundle size. If not, then no further action is needed.
1 participant
Summary by CodeRabbit
These internal enhancements improve code quality and consistency without altering end-user functionality.