express-zod-api - npm Package Versions

v20.22.0

• Featuring a helper to describe nested Routing for already assigned routes:
  • Suppose you want to describe Routing for both /v1/path and /v1/path/subpath routes having Endpoints attached;
  • Previously, an empty path segment was proposed for that purpose, but there is more elegant and readable way now;
  • The .nest() method is available both on Endpoint and DependsOnMethod instances:

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

// Describing routes /v1/path and /v1/path/subpath both having endpoints assigned:
const before: Routing = {
  v1: {
    path: {
      "": endpointA,
      subpath: endpointB,
    },
  },
};

const after: Routing = {
  v1: {
    path: endpointA.nest({
      subpath: endpointB,
    }),
  },
};

v20.21.2

• Fixed the example implementation in the generated client for endpoints using path params:
  • The choice of parser was made based on the exported const jsonEndpoints indexed by path;
  • The actual path used for the lookup already contained parameter substitutions so that JSON parser didn't work;
  • The new example implementation suggests choosing the parser based on the actual response.headers;
  • The issue was found and reported by @HenriJ.

- const parser = `${method} ${path}` in jsonEndpoints ? "json" : "text";
+ const isJSON = response.headers
+   .get("content-type")
+   ?.startsWith("application/json");
- return response[parser]();
+ return response[isJSON ? "json" : "text"]();

v20.21.1

• Performance tuning: Routing traverse made about 12 times faster.

v20.21.0

• Feat: input schema made optional:
  • The input property can be now omitted on the argument of the following methods: Middlware::constructor, EndpointsFactory::build(), EndpointsFactory::addMiddleware();
  • When the input schema is not specified z.object({}) is used;
  • This feature aims to simplify the implementation for Endpoints and Middlwares having no inputs.

v20.20.1

• Minor code style refactoring and performance tuning;
• The software is redefined as a framework;
  • Thanks to @JonParton for contribution to the documentation.

v20.20.0

• Introducing errorHandler option for testMiddleware() method:
  • If your middleware throws an error there was no ability to make assertions other than the thrown error;
  • New option can be assigned with a function for transforming the error into response, so that testMiddlware itself would not throw, enabling usage of all returned entities for mutiple assertions in test;
  • The feature suggested by @williamgcampbell.

import { testMiddleware, Middleware } from "express-zod-api";

const middlware = new Middleware({
  input: z.object({}),
  handler: async ({ logger }) => {
    logger.info("logging something");
    throw new Error("something went wrong");
  },
});

test("a middleware throws, but it writes log as well", async () => {
  const { loggerMock, responseMock } = await testMiddleware({
    errorHandler: (error, response) => response.end(error.message),
    middleware,
  });
  expect(loggerMock._getLogs().info).toEqual([["logging something"]]);
  expect(responseMock._getData()).toBe("something went wrong");
});