express-zod-api/src/endpoints-factory.ts (1)

55-56: Nit: tighten JSDoc wording for clarity.

“defined by Routing” can read as behavior-driven; suggest “defined in Routing keys” to point at the declaration site.

-   * @default "get" unless method is explicitly defined by Routing
+   * @default "get" unless method is explicitly defined in Routing keys

CHANGELOG.md (1)

7-19: v26 entry looks good; add one migration hint re HEAD.

Many users relied on implicit HEAD with GET. A one-line note here will reduce confusion.

 ### v26.0.0

 - `DependsOnMethod` removed: use flat syntax with explicit method and a slash;
+  - Note: HEAD remains auto-handled for endpoints that support GET; no `"head /"` mapping is required.

migration/index.ts (1)

88-91: Tiny consistency nit: keep trailing commas in fallback branch.

Add a trailing comma after the manual-migration comment for uniform diffs and to match outputs in tests.

-                  : `${ctx.sourceCode.getText(prop)}, /** @todo migrate manually */`;
+                  : `${ctx.sourceCode.getText(prop)}, /** @todo migrate manually */,`;

migration/index.spec.ts (1)

20-68: Add test coverage: string-literal keys and chained .deprecated().nest() orders.

These cases guard against regressions in the fixer and reflect how real code may appear.

   tester.run("v26", migration.rules.v26, {
     valid: [`const routing = { "get /": someEndpoint };`],
     invalid: [
+      {
+        name: "string-literal method key",
+        code: `const routing = new DependsOnMethod({ "get": someEndpoint });`,
+        output: `const routing = {\n"get /": someEndpoint,\n};`,
+        errors: [{ messageId: "change", data: { subject: "value", from: "new DependsOnMethod(...)", to: "its argument object and append its keys with ' /'" } }],
+      },
       {
         name: "basic DependsOnMethod",
         code: `const routing = new DependsOnMethod({ get: someEndpoint });`,
         output: `const routing = {\n"get /": someEndpoint,\n};`,
         errors: [
           {
             messageId: "change",
             data: {
               subject: "value",
               from: "new DependsOnMethod(...)",
               to: "its argument object and append its keys with ' /'",
             },
           },
         ],
       },
+      {
+        name: "deprecated + nest (deprecated before nest)",
+        code: `const routing = new DependsOnMethod({ get: epA }).deprecated().nest({ some: epB });`,
+        output: `const routing = {\n"get /": epA.deprecated(),\n"some": epB,\n};`,
+        errors: [{ messageId: "change", data: { subject: "value", from: "new DependsOnMethod(...)", to: "its argument object and append its keys with ' /'" } }],
+      },
+      {
+        name: "deprecated + nest (nest before deprecated)",
+        code: `const routing = new DependsOnMethod({ get: epA }).nest({ some: epB }).deprecated();`,
+        output: `const routing = {\n"get /": epA.deprecated(),\n"some": epB,\n};`,
+        errors: [{ messageId: "change", data: { subject: "value", from: "new DependsOnMethod(...)", to: "its argument object and append its keys with ' /'" } }],
+      },
       {
         name: "deprecated DependsOnMethod",
         code: `const routing = new DependsOnMethod({ get: someEndpoint }).deprecated();`,
         output: `const routing = {\n"get /": someEndpoint.deprecated(),\n};`,
         errors: [
           {
             messageId: "change",
             data: {
               subject: "value",
               from: "new DependsOnMethod(...)",
               to: "its argument object and append its keys with ' /'",
             },
           },
         ],
       },
       {
         name: "DependsOnMethod with nesting",
         code: `const routing = new DependsOnMethod({ get: someEndpoint }).nest({ some: otherEndpoint });`,
         output: `const routing = {\n"get /": someEndpoint,\n"some": otherEndpoint,\n};`,
         errors: [
           {
             messageId: "change",
             data: {
               subject: "value",
               from: "new DependsOnMethod(...)",
               to: "its argument object and append its keys with ' /'",
             },
           },
         ],
       },
     ],
   });

README.md (1)

301-306: LGTM: method-based routing example matches the new syntax.

Clear illustration of "METHOD /" keys under a path. Consider a side note that HEAD is auto-handled for GET (no "head /" needed).

example/routing.ts (1)

1-1: Use a type-only import for Routing

To avoid emitting a value import in JS builds (and to play nicely with TS “verbatimModuleSyntax”), import Routing as a type.

-import { Routing, ServeStatic } from "express-zod-api";
+import type { Routing } from "express-zod-api";
+import { ServeStatic } from "express-zod-api";

express-zod-api/src/routing.ts (1)

7-7: Correct: type-only import for AbstractEndpoint

This avoids runtime imports; matches the library’s typing style. While here, consider also marking OnEndpoint as a type-only import for consistency.

-import { OnEndpoint, walkRouting } from "./routing-walker";
+import type { OnEndpoint } from "./routing-walker";
+import { walkRouting } from "./routing-walker";

express-zod-api/src/endpoint.ts (1)

44-49: Avoid mutating arguments in .nest()

Object.assign mutates the provided routing object. Prefer returning a new object (keeps surprises low for callers).

-  public nest(routing: Routing): Routing {
-    return Object.assign(routing, { "": this });
-  }
+  public nest(routing: Routing): Routing {
+    return { "": this, ...routing };
+  }

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Learnt from: RobinTail
PR: RobinTail/express-zod-api#2428
File: express-zod-api/src/index.ts:44-44
Timestamp: 2025-05-28T18:58:10.064Z
Learning: The type-only import `import type {} from "qs";` in express-zod-api/src/index.ts is necessary to avoid TS2742 errors for exported functions like attachRouting, makeRequestMock, testEndpoint, and testMiddleware that have types depending on types/qs. This import provides the reference TypeScript needs to infer portable type names.

Learnt from: RobinTail
PR: RobinTail/express-zod-api#2546
File: example/factories.ts:35-42
Timestamp: 2025-05-27T20:03:34.213Z
Learning: The `./example` directory in the express-zod-api repository contains demonstration code for educational purposes only, not intended for production use. Example code can make simplified assumptions for brevity and clarity, and should not be flagged for missing production-level error handling, security measures, or edge case handling.

Learnt from: RobinTail
PR: RobinTail/express-zod-api#2546
File: express-zod-api/src/json-schema-helpers.ts:1-3
Timestamp: 2025-05-27T20:27:17.015Z
Learning: Ramda is correctly listed as a dependency in express-zod-api/package.json, so imports of ramda utilities are properly supported.

Learnt from: RobinTail
PR: RobinTail/express-zod-api#2546
File: express-zod-api/src/documentation-helpers.ts:508-512
Timestamp: 2025-05-28T07:58:09.853Z
Learning: In express-zod-api, when working with Zod's JSON schema override callbacks, using `delete` to mutate `ctx.jsonSchema` is the recommended approach per Zod's official documentation, even if it triggers performance linting warnings. This is preferable to creating copies with `undefined` values, especially for snapshot testing.