express-zod-api - npm Package Versions

v22.10.1

• Fixed catching errors in a custom ResultHandler used as errorHandler for Not Found routes having async handler.

// reproduction
import { createConfig, ResultHandler } from "express-zod-api";

createConfig({
  errorHandler: new ResultHandler({
    // rejected promise was not awaited:
    handler: async () => {
      throw new Error(
        "You should not do it. But if you do, we've got LastResortHandler to catch it.",
      );
    },
  }),
});

v22.10.0

• Featuring required request bodies in the generated Documentation:
  • This version sets the required property to requestBody when:
    • It contains the required properties on it;
    • Or it's based on ez.raw() (proprietary schema);
  • The presence of requestBody depends on the Endpoint method(s) and the configuration of inputSources;
  • The lack of the property was reported by @LufyCZ.

v22.9.1

• Minor refactoring and optimizations.

v22.9.0

• Featuring Deprecations:
  • You can deprecate all usage of an Endpoint using EndpointsFactory::build({ deprecated: true });
  • You can deprecate a route using the assigned Endpoint::deprecated() or DependsOnMethod::deprecated();
  • You can deprecate a schema using ZodType::deprecated();
  • All .deprecated() methods are immutable — they create a new copy of the subject;
  • Deprecated schemas and endpoints are reflected in the generated Documentation and Integration;
  • The feature suggested by @mlms13.

import { Routing, DependsOnMethod } from "express-zod-api";
import { z } from "zod";

const someEndpoint = factory.build({
  deprecated: true, // deprecates all routes the endpoint assigned to
  input: z.object({
    prop: z.string().deprecated(), // deprecates the property or a path parameter
  }),
});

const routing: Routing = {
  v1: oldEndpoint.deprecated(), // deprecates the /v1 path
  v2: new DependsOnMethod({ get: oldEndpoint }).deprecated(), // deprecates the /v2 path
  v3: someEndpoint, // the path is assigned with initially deprecated endpoint (also deprecated)
};

v22.8.0

• Feature: warning about the endpoint input scheme ignoring the parameters of the route to which it is assigned:
  • There is a technological gap between routing and endpoints, which at the same time allows an endpoint to be reused across multiple routes. Therefore, there are no constraints between the route parameters and the input schema;
  • This version introduces checking for such discrepancies:
    • non-use of the path parameter or,
    • a mistake in manually entering its name;
  • The warning is displayed when the application is launched and NOT in production mode.

const updateUserEndpoint = factory.build({
  method: "patch",
  input: z.object({
    id: z.string(), // implies path parameter "id"
  }),
});

const routing: Routing = {
  v1: {
    user: {
      ":username": updateUserEndpoint, // path parameter is "username" instead of "id"
    },
  },
};

warn: The input schema of the endpoint is most likely missing the parameter of the path it is assigned to.
      { method: 'patch', path: '/v1/user/:username', param: 'username' }

v22.7.0

• Technical release in connection with the implementation of workspaces into the project architecture.

v22.6.0

• Feature: pulling examples up from the object schema properties:
  • When describing I/O schemas for generating Documentation the examples used to work properly only when assigned to the top level (z.object().example()), especially complex scenarios involving path parameters and middlewares;
  • This version supports examples assigned to the individual properties on the I/O object schemas;
  • It makes the syntax more readable and fixes the issue when example is only set for a path parameter.

const before = factory.build({
  input: z
    .object({
      key: z.string(),
    })
    .example({
      key: "1234-5678-90",
    }),
});

const after = factory.build({
  input: z.object({
    key: z.string().example("1234-5678-90"),
  }),
});

v22.5.0

• Feature: defaultResultHandler sets headers from HttpError:
  • If you throw createHttpError(400, "message", { headers }) those headers go to the negative response.
• Feature: Ability to respond with status code 405 (Method not allowed) to requests having wrong method:
  • Previously, in all cases where the method and route combination was not defined, the response had status code 404;
  • For situations where a known route does not support the method being used, there is a more appropriate code 405:
    • See https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/405 for details;
  • You can activate this feature by setting the new wrongMethodBehavior config option 405 (default: 404).

import { createConfig } from "express-zod-api";

createConfig({ wrongMethodBehavior: 405 });

v22.4.2

• Excluded 41 response-only headers from the list of well-known ones used to depict request params in Documentation.