feature/delete-db into main 👽 Delete database and orm, fix prettier errors, delete interceptors for routes and configs#271
feature/delete-db into main 👽 Delete database and orm, fix prettier errors, delete interceptors for routes and configs#271Camon-fi07 wants to merge 6 commits into
Conversation
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Repository UI Review profile: ASSERTIVE Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
WalkthroughThis pull request removes the entire database and ORM functionality from the mock server framework, including database route creation, storage implementations, ORM and storage types, validation schemas, documentation, examples, tests, and related middleware/context injection logic. Changes
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
| }, | ||
| ], | ||
| }, | ||
| path: '/user', |
There was a problem hiding this comment.
тут vs code prettier ошибки поправил, signle quote и т.д. в целом не вижу ничего плохого поэтому решил оставить
Greptile SummaryThis PR removes the database/ORM feature and eliminates route- and request-level interceptors, keeping only component- and server-level interceptors. The server-side implementation and internal types ( Confidence Score: 4/5Not safe to merge until shared public types are aligned with the server's removal of route/request-level interceptors. Three P1 issues exist: the shared package types still advertise interceptors on route configs, request configs, RestConfig, and GraphqlConfig that the server silently ignores. This creates a breaking behavioral regression for any consumer relying on those interception points, with no TypeScript signal. packages/shared/types/rest.ts, packages/shared/types/graphql.ts, packages/shared/types/server.ts — all retain interceptor fields that are no longer wired in the server implementation. Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[Incoming Request] --> B[contextMiddleware]
B --> C{Route matched?}
C -- REST --> D[createRestRoute]
C -- GraphQL --> E[createGraphQLRoute]
D --> F[callRequestInterceptor\nserver-level only]
E --> F
F --> G[Process Route Config]
G --> H[callResponseInterceptors]
H --> I{Which interceptors?}
I --> J[componentInterceptor]
I --> K[serverInterceptor]
J --> L[Final Response]
K --> L
style B fill:#f9c,stroke:#c00
style F fill:#cfc,stroke:#090
note1["❌ Removed: orm context\n❌ Removed: route/request interceptors\n❌ Removed: database routes"]
Reviews (2): Last reviewed commit: "feature/delete-db 👽 delete interceptors..." | Re-trigger Greptile |
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
Camon-fi07
changed the title
|
Из старых типов которые вроде как уже не используются не стал удалять interceptors, они все равно позже удалятся |
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| settings?: RestSettings & { polling?: false }; | ||
| file: RestFileResponse; | ||
| } | ||
| ) & { entities?: RestEntitiesByEntityName<Method>; interceptors?: Interceptors<'rest'> }; | ||
| ) & { entities?: RestEntitiesByEntityName<Method>; interceptors?: Interceptors }; | ||
|
|
||
| export type RestPathString = `/${string}`; | ||
|
|
||
| interface BaseRestRequestConfig<Method extends RestMethod> { | ||
| interceptors?: Interceptors<'rest'>; | ||
| interceptors?: Interceptors; | ||
| method: Method; |
There was a problem hiding this comment.
interceptors on route/request configs silently ignored after server-side removal
The interceptors field is kept on RestRouteConfig (line 56) and BaseRestRequestConfig (line 62) in the shared types, but createMockServer.ts no longer maps config.interceptors or route.interceptors into the request artifacts. Any consumer who defines interceptors at the route or request-config level will receive no error — their interceptors will simply never be called. The server-side types in packages/server/src/utils/types/rest.ts correctly remove these fields; the shared types should match to avoid a misleading public API surface.
| settings?: GraphQLSettings & { polling?: false }; | ||
| data: GraphqlDataResponse; | ||
| } | ||
| ) & { entities?: GraphQLEntitiesByEntityName; interceptors?: Interceptors<'graphql'> }; | ||
| ) & { entities?: GraphQLEntitiesByEntityName; interceptors?: Interceptors }; | ||
|
|
||
| interface BaseGraphQLRequestConfig { | ||
| interceptors?: Interceptors<'graphql'>; | ||
| interceptors?: Interceptors; | ||
| operationType: GraphQLOperationType; | ||
| routes: GraphQLRouteConfig[]; | ||
| } |
There was a problem hiding this comment.
interceptors on GraphQL route/request configs silently ignored
Same issue as shared/types/rest.ts: interceptors is retained on GraphQLRouteConfig (line 41) and BaseGraphQLRequestConfig (line 45), but the server no longer wires these into request artifacts. Callers relying on route- or request-level GraphQL interceptors will experience silent no-ops with no TypeScript error to guide them. These fields should be removed to match the server's internal packages/server/src/utils/types/graphql.ts where they were correctly dropped.
| export interface RestConfig { | ||
| baseUrl?: BaseUrl; | ||
| configs: RestRequestConfig[]; | ||
| interceptors?: Interceptors<'rest'>; | ||
| interceptors?: Interceptors; | ||
| } | ||
|
|
||
| export interface GraphqlConfig { | ||
| baseUrl?: BaseUrl; | ||
| configs: GraphQLRequestConfig[]; | ||
| interceptors?: Interceptors<'graphql'>; | ||
| } | ||
|
|
||
| export interface DatabaseConfig { | ||
| data: `${string}.json` | Record<string, unknown>; | ||
| routes?: `${string}.json` | Record<`/${string}`, `/${string}`>; | ||
| interceptors?: Interceptors; | ||
| } | ||
|
|
||
| export interface BaseMockServerConfig { |
There was a problem hiding this comment.
interceptors on RestConfig/GraphqlConfig silently ignored
RestConfig.interceptors and GraphqlConfig.interceptors remain in the shared types (lines 36, 43), but createMockServer.ts only reads interceptors from the top-level MockServerSettings — not from these component-level config objects. Any consumer who sets interceptors inside a RestConfig or GraphqlConfig block will have them silently dropped. The server's own packages/server/src/utils/types/server.ts already removed these fields; the shared types should follow suit.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
packages/server/src/utils/helpers/interceptors/callResponseInterceptors/callResponseInterceptors.test.ts (1)
3-4:⚠️ Potential issue | 🔴 CriticalMissing
viimport will cause test failures.The
vifunction is still used on lines 19-20 (vi.fn()) for mock interceptors, but it was removed from the vitest imports. This will cause a runtime error when running the tests.🐛 Proposed fix
-import { describe, expect, it } from 'vitest'; +import { describe, expect, it, vi } from 'vitest';🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/server/src/utils/helpers/interceptors/callResponseInterceptors/callResponseInterceptors.test.ts` around lines 3 - 4, The test uses vi.fn() for mocks but removed vi from the vitest import; restore vi in the import statement so the test can call vi.fn(). Update the top-level import (the one currently importing describe, expect, it from vitest) to also include vi (e.g., import { describe, expect, it, vi } from 'vitest') so the mock creation in the CallResponseInterceptors test (where vi.fn() is used) works at runtime.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@packages/docs/content/docs/mocking-requests/references/Interceptors.mdx`:
- Line 83: The docs use a generic Partial<LoggerTokens> for interceptor phases;
change these to phase-specific token types so typings are precise: replace
occurrences of "(logger?: Logger<'request'>) => Partial<LoggerTokens>" with
"(logger?: Logger<'request'>) => Partial<RequestLoggerTokens>" for request-phase
interceptors and similarly use "(logger?: Logger<'response'>) =>
Partial<ResponseLoggerTokens>" (or the exact names used in your codebase) for
response-phase interceptors; update any related examples/signatures and ensure
RequestLoggerTokens/ResponseLoggerTokens are imported or defined where
LoggerTokens was used.
In `@packages/docs/content/docs/mocking-requests/references/Logger.mdx`:
- Line 43: Update the sentence describing LoggerTokens<Type>: remove the stale
reference to Api (`rest` | `graphql`) and rephrase to reflect the new type shape
— e.g., state that LoggerTokens<Type> is an object whose keys are the available
logger tokens for the selected Type (`request` | `response`) and whose values
are the token payloads; ensure the symbol LoggerTokens<Type> and the Type
options (`request` | `response`) are mentioned so readers can locate the correct
type.
In
`@packages/server/src/core/graphql/createGraphQLRoute/createGraphQLRoute.test.ts`:
- Around line 41-42: Remove the unused serverRequestInterceptor field from the
test artifacts and related types: delete any creation/assignment of
serverRequestInterceptor in the artifacts used by createMockServer (references
around the block that sets serverResponseInterceptor/serverRequestInterceptor)
and update the artifact/interface definitions so serverRequestInterceptor is no
longer expected; also remove any test references passing
serverRequestInterceptor into createGraphQLRoute/createRestRoute mocks and
adjust createMockServer middleware usage (the request interception remains
handled in the middleware path), and run/type-check to update affected tests and
types (look for symbol serverRequestInterceptor and files createMockServer.ts,
createGraphQLRoute.ts, createRestRoute.ts).
---
Outside diff comments:
In
`@packages/server/src/utils/helpers/interceptors/callResponseInterceptors/callResponseInterceptors.test.ts`:
- Around line 3-4: The test uses vi.fn() for mocks but removed vi from the
vitest import; restore vi in the import statement so the test can call vi.fn().
Update the top-level import (the one currently importing describe, expect, it
from vitest) to also include vi (e.g., import { describe, expect, it, vi } from
'vitest') so the mock creation in the CallResponseInterceptors test (where
vi.fn() is used) works at runtime.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: e5121a5f-a9d4-4272-88a7-d7ba0f80f366
📒 Files selected for processing (26)
packages/docs/content/docs/mocking-requests/references/GraphQL.mdxpackages/docs/content/docs/mocking-requests/references/Interceptors.mdxpackages/docs/content/docs/mocking-requests/references/Logger.mdxpackages/docs/content/docs/mocking-requests/references/Rest.mdxpackages/server/README.mdpackages/server/src/core/graphql/createGraphQLRoute/createGraphQLRoute.test.tspackages/server/src/core/graphql/createGraphQLRoute/createGraphQLRoute.tspackages/server/src/core/rest/createRestRoute/createRestRoute.test.tspackages/server/src/core/rest/createRestRoute/createRestRoute.tspackages/server/src/server/createMockServer/createMockServer.tspackages/server/src/utils/helpers/interceptors/callResponseInterceptors/callResponseInterceptors.test.tspackages/server/src/utils/helpers/interceptors/callResponseInterceptors/callResponseInterceptors.tspackages/server/src/utils/types/graphql.tspackages/server/src/utils/types/index.tspackages/server/src/utils/types/interceptors.tspackages/server/src/utils/types/logger.tspackages/server/src/utils/types/rest.tspackages/server/src/utils/types/server.tspackages/server/src/utils/types/shared.tspackages/shared/types/graphql.tspackages/shared/types/index.tspackages/shared/types/interceptors.tspackages/shared/types/logger.tspackages/shared/types/rest.tspackages/shared/types/server.tspackages/shared/types/shared.ts
💤 Files with no reviewable changes (7)
- packages/shared/types/shared.ts
- packages/server/src/utils/types/shared.ts
- packages/server/src/core/graphql/createGraphQLRoute/createGraphQLRoute.ts
- packages/server/src/utils/types/index.ts
- packages/shared/types/index.ts
- packages/server/src/core/rest/createRestRoute/createRestRoute.ts
- packages/server/src/utils/types/server.ts
| log: { | ||
| description: 'Log request data', | ||
| type: "(logger?: Logger<'request', Api>) => Partial<LoggerTokens>", | ||
| type: "(logger?: Logger<'request'>) => Partial<LoggerTokens>", |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Specialize LoggerTokens by interceptor phase for clearer typing.
Line 83 and Line 154 currently return Partial<LoggerTokens>. Using request/response-specialized token types would make the docs more precise.
Proposed refinement
- type: "(logger?: Logger<'request'>) => Partial<LoggerTokens>",
+ type: "(logger?: Logger<'request'>) => Partial<LoggerTokens<'request'>>",- type: "(logger?: Logger<'response'>) => Partial<LoggerTokens>",
+ type: "(logger?: Logger<'response'>) => Partial<LoggerTokens<'response'>>",Also applies to: 154-154
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@packages/docs/content/docs/mocking-requests/references/Interceptors.mdx` at
line 83, The docs use a generic Partial<LoggerTokens> for interceptor phases;
change these to phase-specific token types so typings are precise: replace
occurrences of "(logger?: Logger<'request'>) => Partial<LoggerTokens>" with
"(logger?: Logger<'request'>) => Partial<RequestLoggerTokens>" for request-phase
interceptors and similarly use "(logger?: Logger<'response'>) =>
Partial<ResponseLoggerTokens>" (or the exact names used in your codebase) for
response-phase interceptors; update any related examples/signatures and ensure
RequestLoggerTokens/ResponseLoggerTokens are imported or defined where
LoggerTokens was used.
| ## LoggerTokens | ||
|
|
||
| `LoggerTokens<Type, Api>` is an object where keys are [available logger tokens](#available-logger-tokens) for the selected `Type` (`request` | `response`) and `Api` (`rest` | `graphql`), and values are token payloads. | ||
| `LoggerTokens<Type>` is an object where keys are [available logger tokens](#available-logger-tokens) for the selected `Type` (`request` | `response`) and `Api` (`rest` | `graphql`), and values are token payloads. |
There was a problem hiding this comment.
Remove stale Api reference from LoggerTokens description.
Line 43 still says LoggerTokens<Type> depends on Api (rest | graphql), which conflicts with the new type shape documented on this page.
Proposed doc fix
-`LoggerTokens<Type>` is an object where keys are [available logger tokens](`#available-logger-tokens`) for the selected `Type` (`request` | `response`) and `Api` (`rest` | `graphql`), and values are token payloads.
+`LoggerTokens<Type>` is an object where keys are [available logger tokens](`#available-logger-tokens`) for the selected `Type` (`request` | `response`), and values are token payloads.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| `LoggerTokens<Type>` is an object where keys are [available logger tokens](#available-logger-tokens) for the selected `Type` (`request` | `response`) and `Api` (`rest` | `graphql`), and values are token payloads. | |
| `LoggerTokens<Type>` is an object where keys are [available logger tokens](`#available-logger-tokens`) for the selected `Type` (`request` | `response`), and values are token payloads. |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@packages/docs/content/docs/mocking-requests/references/Logger.mdx` at line
43, Update the sentence describing LoggerTokens<Type>: remove the stale
reference to Api (`rest` | `graphql`) and rephrase to reflect the new type shape
— e.g., state that LoggerTokens<Type> is an object whose keys are the available
logger tokens for the selected Type (`request` | `response`) and whose values
are the token payloads; ensure the symbol LoggerTokens<Type> and the Type
options (`request` | `response`) are mentioned so readers can locate the correct
type.
| serverResponseInterceptor: interceptors?.response, | ||
| serverRequestInterceptor: interceptors?.request, |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify serverRequestInterceptor usage in route creation files
echo "=== Checking serverRequestInterceptor usage in createGraphQLRoute.ts ==="
rg -n 'serverRequestInterceptor' packages/server/src/core/graphql/createGraphQLRoute/createGraphQLRoute.ts
echo ""
echo "=== Checking serverRequestInterceptor usage in createRestRoute.ts ==="
rg -n 'serverRequestInterceptor' packages/server/src/core/rest/createRestRoute/createRestRoute.ts
echo ""
echo "=== Checking where serverRequestInterceptor is actually used ==="
rg -n 'serverRequestInterceptor' packages/server/src --type ts -C2Repository: siberiacancode/mock-config
Length of output: 4661
Remove unused serverRequestInterceptor from artifacts.
The field is passed in both REST and GraphQL artifacts (in createMockServer.ts lines 90–112) but never invoked in the route creation code (createGraphQLRoute.ts and createRestRoute.ts). Server-level request interception is handled by middleware in createMockServer.ts (lines 57–63), making the field in artifacts redundant.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In
`@packages/server/src/core/graphql/createGraphQLRoute/createGraphQLRoute.test.ts`
around lines 41 - 42, Remove the unused serverRequestInterceptor field from the
test artifacts and related types: delete any creation/assignment of
serverRequestInterceptor in the artifacts used by createMockServer (references
around the block that sets serverResponseInterceptor/serverRequestInterceptor)
and update the artifact/interface definitions so serverRequestInterceptor is no
longer expected; also remove any test references passing
serverRequestInterceptor into createGraphQLRoute/createRestRoute mocks and
adjust createMockServer middleware usage (the request interception remains
handled in the middleware path), and run/type-check to update affected tests and
types (look for symbol serverRequestInterceptor and files createMockServer.ts,
createGraphQLRoute.ts, createRestRoute.ts).
| : Api extends 'graphql' | ||
| ? LoggerGraphQLRequestTokens | ||
| : never | ||
| export type LoggerTokens<Type extends LoggerType = LoggerType> = Type extends 'request' |
There was a problem hiding this comment.
По сути API generic прокидывался только в интерцепторе запроса, которого теперь нет
|
Не удалял interceptors поля из старых интерфейсов, которые больше не используются |
| response?: ResponseInterceptor<any, Api>; | ||
| export interface Interceptors { | ||
| request?: RequestInterceptor; | ||
| response?: ResponseInterceptor<any>; |
There was a problem hiding this comment.
этот дженерик ничего не делает
| response?: ResponseInterceptor<any, Api>; | ||
| export interface Interceptors { | ||
| request?: RequestInterceptor; | ||
| response?: ResponseInterceptor<any>; |
3 participants
Summary by CodeRabbit
Features Removed
Documentation