openapi-msw - npm Package Versions

1.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.

1.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.

0.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.

0.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.

0.6.1

Patch Changes

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

0.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.

0.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 });
  });
  

0.4.0

Minor Changes

• #42 c466bbc Thanks @christoph-fricke! - Changed response body types to be a union of all response bodies for all status codes and media types. This makes it possible to return responses for specified error codes without requiring a type cast. Imagine the following endpoint. Its response body is now typed as StrictResponse<{ id: string, value: number } | string | null>.

  /resource:
    get:
      summary: Get Resource
      operationId: getResource
      responses:
        200:
          description: Success
          content:
            application/json:
              schema:
                type: object
                required: [id, value]
                properties:
                  id:
                    type: string
                  value:
                    type: integer
        202:
          description: Accepted
          content:
            text/plain:
              schema:
                type: string
        418:
          description: NoContent
  

Patch Changes

• #44 a9338b5 Thanks @christoph-fricke! - Fixed endpoints with no specified query params allow any query key in the query helper methods. Now, providing any query key causes a type error.

0.3.0

Minor Changes

• #33 1f3958d Thanks @christoph-fricke! - Added query helper to resolver-info argument. It provides a type-safe wrapper around URLSearchParams for reading search parameters. As usual, the information about available parameters is inferred from your OpenAPI spec.

  /*
  Imagine this endpoint specification for the following example:
  
  /query-example:
    get:
      summary: Query Example
      operationId: getQueryExample
      parameters:
        - name: filter
          in: query
          required: true
          schema:
            type: string
        - name: page
          in: query
          schema:
            type: number
        - name: sort
          in: query
          required: false
          schema:
            type: string
            enum: ["asc", "desc"]
        - name: sortBy
          in: query
          schema:
            type: array
            items:
              type: string
  */
  
  const handler = http.get("/query-example", ({ query }) => {
    const filter = query.get("filter"); // Typed as string
    const page = query.get("page"); // Typed as string | null since it is not required
    const sort = query.get("sort"); // Typed as "asc" | "desc" | null
    const sortBy = query.getAll("sortBy"); // Typed as string[]
  
    // Supported methods from URLSearchParams: get(), getAll(), has(), size
    if (query.has("sort", "asc")) {
      /* ... */
    }
  
    return HttpResponse.json({
      /* ... */
    });
  });
  

• #35 07fa9b0 Thanks @christoph-fricke! - Restructured the library to add support for additional response resolver info. The enhanced ResponseResolver type and ResponseResolverInfo are available as exports.

0.2.2

Patch Changes

• #31 556dfca Thanks @christoph-fricke! - Fixed a type mismatch between path fragment types and the values provided at runtime, which are always strings. Now all path-fragments are typed as string. If a fragment's schema is a string constrained by an enum, the resulting string literals are preserved. This fixes bug #22.

  const handler = http.get("/resource/{id}", ({ params }) => {
    // Previously calling "parseInt(...)" caused a type error
    // when the schema type for "id" is defined as number.
    const id = parseInt(params.id);
  
    return HttpResponse.json({ id });
  });