Restore concise schema DSL with verb helpers, plain runtype responses, and path param validation

[Copilot]

• Normalize endpoint keys (with or without leading slash) using verb helpers and auto-wrap runtype objects
• Exclude body on non-body verbs; update APISchema types and generateAPISchema
• Enforce path parameter inference/validation (derive param names from the route, reject mismatches, omit path when no params)
• Align runtime server/export/implements with flattened schema shape
• Update tests and test script; run targeted test suite

Original prompt

The last PR #1 merged in main broke all types. The __tests__ are not working. Please read the PR and fix the issues created.

The schematype and other parts of the code was changed in a wrong way. The PR indroduce a new property fields that was not requested and force to use Record type to define a responses.

const schema = {
      fields: {
        'GET /users/{id}': {
          fields: {
            request: {
              path: { id: Number },
            },
            responses: {
              200: Record({ name: String }),
              404: Record({ error: String }),
            },
          },
        },
      },
    };

Proposal for define a schema using predefined types for http verbs POST, GET, ..

const schema = {
        `users/{id}`: POST({
            path: {id: String }
            query: { details: Boolean},
            body: { name: String, email: String },
            responses: {
              200: { id: String, name: String, email: String }
              404: { error: String }
            },
          }),
        };

Analyze the #1 PR and update the code following the Proposal schema definition. Before write any code, come back with a detailed review and a plan. Ask for any questions or concerns if you have any dubt .

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[hanc2006]

@copilot Should endpoint keys in user-facing schemas include a leading slash ('users/{id}' vs '/users/{id}'), or should I normalize both?

• normalize both

Can I assume request/response definitions may be plain runtype-object literals (e.g., { id: String }) and I should auto-wrap them (with Record) for runtime guards?

• Yes, correct

Is body optional for GET by definition (i.e., disallow bodies for GET/DELETE), or should I just rely on the helpers’ defaults?

• when http verbs not allow Body, the property should be excluded.

[Copilot]

@copilot Should endpoint keys in user-facing schemas include a leading slash ('users/{id}' vs '/users/{id}'), or should I normalize both?

• normalize both
  ...

Implemented: paths now normalize with or without leading slash, request/response objects are auto-wrapped into runtypes, and body is omitted for verbs that don’t allow it. (49d30ea)

[hanc2006]

@copilot your changes add a lot of issues! The #file:schema.ts as many errors

[Copilot]

@copilot your changes add a lot of issues! The #file:schema.ts as many errors

Schema type errors fixed: relaxed runtype detection, adjusted auto-wrapping, and type-checked cleanly (76221e5).

[hanc2006]

@copilot The path inference is not working. The follow example in #file:schema.test.ts

1. The id is not extracted from the path 'users/{id}' and is not suggested.
2. The path value is not typed! The follow value is valid path: { www: Number } but www is not a valid parameter name!
3. The path property should be excluded when the path string not contains a valid params.

 const schema = {
      'users/{id}': GET({
        path: { id: Number },
        responses: {
          200: { name: String },
          404: { error: String },
        },
      }),
    };

[Copilot]

@copilot The path inference is not working. The follow example in #file:schema.test.ts

1. The id is not extracted from the path 'users/{id}' and is not suggested....

Path params are now inferred and validated: keys are derived from the route template, invalid names like path: { www: Number } are rejected, and path is disallowed when the route has no params. (66c1fce)