Security News
Research
Data Theft Repackaged: A Case Study in Malicious Wrapper Packages on npm
The Socket Research Team breaks down a malicious wrapper package that uses obfuscation to harvest credentials and exfiltrate sensitive data.
openapi-msw
Advanced tools
Tiny, type-safe wrapper around MSW for type inference from OpenAPI schemas.
A tiny, type-safe wrapper around MSW to add support for full type inference from OpenAPI schema definitions that are generated with OpenAPI-TS.
You can install OpenAPI-MSW with this shell command:
npm i -D openapi-msw
Note: This package has a peer-dependency to MSW v2. There is no plan to provide backwards compatibility for MSW v1.
This guide assumes that you already have OpenAPI-TS set up and configured to
generate paths
definitions. If you have not set it up, please refer to the
OpenAPI-TS setup guide before
continuing with this usage guide.
Once you have your OpenAPI schema types ready-to-go, you can use OpenAPI-MSW to
create an enhanced version of MSW's http
object. The enhanced version is
designed to be almost identical to MSW in usage. To go beyond MSW's typing
capabilities, OpenAPI-MSW provides optional helpers for an even better type-safe
experience. Using the http
object created with OpenAPI-MSW enables multiple
type-safety and editor suggestion benefits:
import { HttpResponse } from "msw";
import { createOpenApiHttp } from "openapi-msw";
// 1. Import the paths from your OpenAPI schema definitions
import type { paths } from "./your-openapi-schema";
// 2. Provide your paths definition to enable the above benefits during usage
const http = createOpenApiHttp<paths>();
// TS only suggests available GET paths
const getHandler = http.get("/resource/{id}", ({ params, response }) => {
const id = params.id;
return response(200).json({ id /* ... more response data */ });
});
// TS only suggests available POST paths
const postHandler = http.post(
"/resource",
async ({ request, query, response }) => {
const sortDir = query.get("sort");
const data = await request.json();
return response(201).json({ ...data /* ... more response data */ });
},
);
// TS shows an error when "/unknown" is not defined in the OpenAPI schema paths
const otherHandler = http.get("/unknown", () => {
return new HttpResponse();
});
You can provide an optional base URL to createOpenApiHttp
, which is prepended
to all paths. This is especially useful when your application calls your API on
a subpath or another domain. The value can be any string that is resolvable by
MSW.
const http = createOpenApiHttp<paths>({ baseUrl: "/api/rest" });
// Requests will be matched by MSW against "/api/rest/resource"
export const getHandler = http.get("/resource", () => {
return HttpResponse.json(/* ... */);
});
MSW handlers can be very flexible with the ability to define wildcards (*) in a
path. This can be very useful for catch-all handlers but clashes with your
OpenAPI spec, since it probably is not an endpoint of your API. To define
handlers that are unknown to your OpenAPI spec, you can access the original
http
object through http.untyped
.
const http = createOpenApiHttp<paths>();
// Fallback to MSW's original implementation and typings
const catchAll = http.untyped.all("/resource/*", ({ params }) => {
return HttpResponse.json(/* ... */);
});
Alternatively, you can import the original http
object from MSW and use that
one for unknown paths instead.
For an even better type-safe experience, OpenAPI-MSW provides optional helpers
that are attached to MSW's resolver-info argument. Currently, the helper query
is provided for type-safe access to query parameters. Furthermore, the helper
response
can be used for enhanced type-safety when creating HTTP responses.
query
HelperType-safe wrapper around
URLSearchParams
that implements methods for reading query parameters. For the following example,
imagine an OpenAPI specification that defines some query parameters:
const http = createOpenApiHttp<paths>();
const handler = http.get("/query-example", ({ query }) => {
const filter = query.get("filter"); // string
const sort = query.get("sort"); // "asc" | "desc" | null
const sortBy = query.getAll("sortBy"); // string[]
// Supported methods from URLSearchParams: get(), getAll(), has(), size
if (query.has("sort", "asc")) {
/* ... */
}
return HttpResponse.json({
/* ... */
});
});
response
HelperType-safe response constructor that narrows allowed response bodies based on the
chosen status code and content type. This helper enables granular type-safety
for 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.
For the following example, imagine an OpenAPI specification that defines various responses for an endpoint:
Status Code | Content Type | Content |
---|---|---|
200 | application/json | Some Object Schema |
200 | text/plain | Literal: "Hello World" |
204 | Empty |
const http = createOpenApiHttp<paths>();
const handler = http.get("/response-example", ({ response }) => {
// Error: Status Code 204 only allows empty responses
const invalidRes = response(204).text("Hello World");
// Error: Status Code 200 does not allow empty responses
const invalidRes = response(200).empty();
// Error: Status Code 200 only allows "Hello World" 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 World");
// No Error: This combination is part of the defined OpenAPI spec
const validRes = response(200).json({
/* ... */
});
});
The OpenAPI specification allows the
definition of wildcard status codes,
such as "default"
, "3XX"
, and "5XX"
. OpenAPI-MSW's response
helper
supports using wildcards as status codes. When a wildcard is used, TypeScript
requires you to provide a matching status code that will be used for the
response. Allowed status codes are inferred by TS and suggested based on
RFC 9110.
Note: The "default"
wildcard is categorized as
"any error status code" in OpenAPI-TS.
To align with this assumption, OpenAPI-MSW only allows matching "4XX"
and
"5XX"
status codes for the response if the "default"
wildcard is used.
const http = createOpenApiHttp<paths>();
const handler = http.get("/wildcard-status-code-example", ({ response }) => {
// Error: A wildcards is used but no status code provided
const invalidRes = response("5XX").text("Fatal Error");
// Error: Provided status code does not match the used wildcard
const invalidRes = response("5XX").text("Fatal Error", { status: 403 });
// Error: Provided status code is not defined in RFC 9110
const invalidRes = response("5XX").text("Fatal Error", { status: 520 });
// No Error: Provided status code matches the used wildcard
const validRes = response("5XX").text("Fatal Error", { status: 503 });
// No Error: "default" wildcard allows 5XX and 4XX status codes
const validRes = response("default").text("Fatal Error", { status: 507 });
});
Sometimes an OpenAPI spec might not define all status codes that are actually
returned by the implementing API. This can be quite common for server error
responses (5XX). Nonetheless, still being able to mock those with MSW through
otherwise fully typed http-handlers is really helpful. OpenAPI-MSW supports this
scenario with an untyped
wrapper on the response
helper, which type-casts
any response into an allowed response.
const http = createOpenApiHttp<paths>();
const handler = http.get("/untyped-response-example", ({ response }) => {
// Any response wrapped with `untyped` can be returned regardless
// of the expected response body.
return response.untyped(
HttpResponse.json({ message: "Teapot" }, { status: 418 }),
);
});
This package is published under the MIT license.
FAQs
Tiny, type-safe wrapper around MSW for type inference from OpenAPI schemas.
We found that openapi-msw demonstrated a healthy version release cadence and project activity because the last version was released less than a year ago. It has 0 open source maintainers collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
Research
The Socket Research Team breaks down a malicious wrapper package that uses obfuscation to harvest credentials and exfiltrate sensitive data.
Research
Security News
Attackers used a malicious npm package typosquatting a popular ESLint plugin to steal sensitive data, execute commands, and exploit developer systems.
Security News
The Ultralytics' PyPI Package was compromised four times in one weekend through GitHub Actions cache poisoning and failure to rotate previously compromised API tokens.