zod-openapi-share 0.0.5 → 0.0.7
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +5 -5
- package/package.json +2 -2
package/README.md
CHANGED
|
@@ -11,7 +11,7 @@
|
|
|
11
11
|
|
|
12
12
|
[](#)
|
|
13
13
|
|
|
14
|
-
`zod-openapi-share` is an extension for `@hono/zod-openapi` that lets you centralize and reuse response definitions across endpoints.
|
|
14
|
+
`zod-openapi-share` is an extension package for `@hono/zod-openapi` that lets you centralize and reuse response definitions across endpoints.
|
|
15
15
|
Normally, `@hono/zod-openapi` requires you to redefine the same responses (e.g., error schemas) for every endpoint, but with `zod-openapi-share`, you can avoid repetition and prevent definition drift, making your backend development using `hono` + `@hono/zod-openapi` cleaner and more consistent.
|
|
16
16
|
|
|
17
17
|
> [!IMPORTANT]
|
|
@@ -20,17 +20,17 @@ Normally, `@hono/zod-openapi` requires you to redefine the same responses (e.g.,
|
|
|
20
20
|
## What is `zod-openapi-share`?
|
|
21
21
|
|
|
22
22
|
In projects using `hono`, you may have opportunities to use a convenient package called `@hono/zod-openapi` as middleware for generating OpenAPI schemas.
|
|
23
|
-
This package allows you to define both
|
|
23
|
+
This package allows you to define both OpenAPI schemas and Zod-based validation at the same time.
|
|
24
24
|
|
|
25
25
|
However, it has a major drawback: you must repeatedly write out the `responses` definitions for every single status code across all endpoints.
|
|
26
26
|
In many cases, error responses share the exact same structure across endpoints — yet, even if they are identical, you still have to duplicate those definitions.
|
|
27
27
|
|
|
28
|
-
To solve this, `zod-openapi-share` provides a way to
|
|
28
|
+
To solve this, `zod-openapi-share` provides a way to centralize and reuse response definitions by wrapping around `@hono/zod-openapi`.
|
|
29
29
|
Think of `zod-openapi-share` as an extension package for `@hono/zod-openapi`.
|
|
30
30
|
When using it, you’ll need three packages together: `hono`, `@hono/zod-openapi`, and `zod-openapi-share`.
|
|
31
31
|
|
|
32
32
|
By unifying response definitions, you can develop without worrying about unintended inconsistencies between endpoints.
|
|
33
|
-
If you’re using hono and @hono/zod-openapi, be sure to try
|
|
33
|
+
If you’re using hono and @hono/zod-openapi, be sure to try `zod-openapi-share`!
|
|
34
34
|
|
|
35
35
|
### before (`hono` + `@hono/zod-openapi`)
|
|
36
36
|
|
|
@@ -427,7 +427,7 @@ export const api = () => {
|
|
|
427
427
|
info: {
|
|
428
428
|
title: 'Echo API',
|
|
429
429
|
version: '1.0.0',
|
|
430
|
-
description: '
|
|
430
|
+
description: 'An example of OpenAPI with hono, @hono/zod-openapi, and zod-openapi-share.',
|
|
431
431
|
},
|
|
432
432
|
});
|
|
433
433
|
|
package/package.json
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "zod-openapi-share",
|
|
3
|
-
"version": "0.0.
|
|
4
|
-
"description": "This package is an extension for @hono/zod-openapi.",
|
|
3
|
+
"version": "0.0.7",
|
|
4
|
+
"description": "This package is an extension package for @hono/zod-openapi.",
|
|
5
5
|
"keywords": [
|
|
6
6
|
"@hono/zod-openapi",
|
|
7
7
|
"hono",
|