v2.0.0

Major Changes

• #90 a7a4b25 Thanks @christoph-fricke! - Removed CommonJS compilation and exports. OpenAPI-MSW now publishes ESM only. All actively maintained Node.js versions support requiring ESM, so const { createOpenApiHttp } = require("openapi-msw"); will still work.

• #94 72fac10 Thanks @christoph-fricke! - Updated MSW peer dependency from v2.7.0 to v2.10.5. This is only a breaking change if you are not already using the latest version of MSW.

Minor Changes

• #91 905b985 Thanks @christoph-fricke! - Added declaration maps to the build output. Together with packaged source files, this enables proper "Go To Definition" support in editors — jumping directly to the TypeScript source file instead of the declaration file.

v1.3.0

Minor Changes

• #87 0a8a892 Thanks @christoph-fricke! - Added a section to the README explaining how to use OpenAPI-MSW handlers with MSW, which provides clearer guidance for integration.

• #88 e7fab35 Thanks @christoph-fricke! - Changed the publishing flow to use trusted publishing via OIDC instead of a token-based approach.

• #86 be6f731 Thanks @christoph-fricke! - Updated TSDoc comments for response and query to show their code examples. Previously, VS Code did not display their @example blocks.

v1.2.0

Minor Changes

• #78 482c028 Thanks @christoph-fricke! - Added utility types for creating type-safe functionality around OpenAPI-MSW. Special thanks to @DrewHoo for suggesting and inspiring this change.

  import {
    createOpenApiHttp,
    type PathsFor,
    type RequestBodyFor,
    type ResponseBodyFor,
  } from "openapi-msw";
  
  const http = createOpenApiHttp<paths>();
  
  // A union of all possible GET paths.
  type Paths = PathsFor<typeof http.get>;
  
  // The request body for POST /tasks.
  type RequestBody = RequestBodyFor<typeof http.post, "/tasks">;
  
  // The response body for GET /tasks.
  type ResponseBody = ResponseBodyFor<typeof http.get, "/tasks">;

v1.1.0

Minor Changes

• #73 f81ae29 Thanks @christoph-fricke! - Added a request.clone() type override to continue returning type-safe OpenApiRequests when called. With this, cloning the request in resolvers does not lose its type-safety on body parsing methods.

v1.0.0

Major Changes

• #70 bc9a50f Thanks @christoph-fricke! - Updated MSW peer dependency from v2.0.0 to v2.7.0. This is only a breaking change if you are not already using the latest version of MSW.

• #70 bc9a50f Thanks @christoph-fricke! - Renamed HttpHandlerFactory type to OpenApiHttpRequestHandler. This rename aligns its name with MSW's equivalent HttpRequestHandler type.

Minor Changes

• #68 33088be Thanks @christoph-fricke! - Removed dependency on openapi-typescript-helpers. We were depending on an older version without being able to easily update. With this refactoring, your projects should no longer resolve to multiple versions of openapi-typescript-helpers.

v0.7.1

Patch Changes

• #63 b9f4bea Thanks @christoph-fricke! - Fixed type inference for extended JSON mime types, such as application/problem+json. Previously, APIs like response(...).json would be typed as never for such mime types. Now, they will be properly typed.

v0.7.0

Minor Changes

• #58 f08acf1 Thanks @christoph-fricke! - Added "content-length" header for response(...).empty(). If no "content-length" header is provided in the response init, the "content-length" header is now set with the value "0". See #56 for more details.

v0.6.1

Patch Changes

• #54 6793dcc Thanks @christoph-fricke! - Fixed type-exports for CommonJS refer to a non-existing file.

v0.6.0

Minor Changes

• #50 37da681 Thanks @christoph-fricke! - Added compilation and exports for CommonJS modules. This makes OpenAPI-MSW usable in projects that still use CommonJS as their module system.

• #52 88ca9da Thanks @christoph-fricke! - Added enhanced typing for the request object. Now, request.json() and request.text() infer their return type from the given OpenAPI request-body content schema. Previously, only request.json() has been inferred without considering the content-type.

v0.5.0

Minor Changes

• #41 fe70d20 Thanks @christoph-fricke! - Added response helper to the resolver-info argument. It provides an granular type-safety when creating HTTP responses. Instead of being able to return any status code, response limits status codes, content types, and their response bodies to the combinations defined by the given OpenAPI spec.

  /*
  Imagine this endpoint specification for the following example:
  
  /response-example:
    get:
      summary: Get Resource
      operationId: getResource
      responses:
        200:
          description: Success
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/Resource"
            text/plain:
              schema:
                type: string
                enum: ["Hello", "Goodbye"]
        204:
          description: NoContent
        "5XX":
          description: Error
          content:
            text/plain:
              schema:
                type: string
  */
  
  const handler = http.get("/response-example", ({ response }) => {
    // Error: Status Code 204 only allows empty responses
    const invalidRes = response(204).text("Hello");
  
    // Error: Status Code 200 only allows "Hello" as text
    const invalidRes = response(200).text("Some other string");
  
    // No Error: This combination is part of the defined OpenAPI spec
    const validRes = response(204).empty();
  
    // No Error: This combination is part of the defined OpenAPI spec
    const validRes = response(200).text("Hello");
  
    // Using a wildcard requires you to provide a matching status code for the response
    const validRes = response("5XX").text("Fatal Error", { status: 503 });
  });