Prepare for v0.4.0 release #165
Conversation
These Zod-specific packages are removed in favor of the more generic std-schema-adapter and std-schema-openapi-plugin packages which support Standard Schema compatible libraries.
- hono: 4.9.8 -> 4.11.3 - @hono/node-server: 1.19.6 -> 1.19.7 - openapi3-ts: 4.4.0 -> 4.5.0 - swagger-ui-dist: 5.29.4 -> 5.31.0 - execa: 9.6.0 -> 9.6.1 - p-limit: 6.2.0 -> 7.2.0
Update devDependencies: - catalog: eslint 9.39.2, vitest 4.0.16, tsdown 0.18.3 - root: @changesets/cli, lefthook 2.x, prettier, turbo, vitepress - eslint-config: @eslint/js, typescript-eslint 8.51.0 - example: cross-env 10.x, pino-pretty, tsx - std-schema-adapter: @standard-schema/spec 1.1.0 Align peer dependencies with dev versions: - std-schema-adapter: @standard-schema/spec ^1.0.0 -> ^1.1.0 - openapi-plugin: openapi3-ts ^4.4.0 -> ^4.5.0 - std-schema-openapi-plugin: openapi3-ts ^4.4.0 -> ^4.5.0
- Update @types/node to 20.19.27 (matching Node 20 support) - Update mise node to 20.19.6 - Update mise lefthook to 2.0.13 - Remove lefthook from package.json (managed by mise only) - Add lefthook install to mise postinstall hook
Move git workflow rules from rules to commands for step-by-step guidance. Remove git.mdc as content is now in command files.
🦋 Changeset detectedLatest commit: 6424258 The changes in this PR will be included in the next version bump. Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
📝 WalkthroughWalkthroughThe PR removes the zod-schema-adapter and zod-openapi-plugin packages entirely, replacing them with std-schema-adapter and std-schema-openapi-plugin. Multiple dependency versions are updated across the workspace. Cursor documentation files are added. TypeScript configuration references updated to reflect removed packages. Swagger UI asset hashes regenerated. Changes
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Possibly related PRs
Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Pull request overview
This PR prepares the repository for v0.4.0 release by removing deprecated packages (zod-schema-adapter and zod-openapi-plugin), updating dependencies, and cleaning up configuration files. The changes align the project to use the new std-schema-adapter and std-schema-openapi-plugin packages instead.
Key Changes:
- Remove
zod-schema-adapterandzod-openapi-pluginpackages - Update runtime and development dependencies to latest versions
- Downgrade
@types/nodefrom 22.x to 20.x to match minimum Node.js support (>=20) - Remove
lefthookfrom package.json (now managed by mise)
Reviewed changes
Copilot reviewed 65 out of 72 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| tsconfig.json | Removed references to deleted packages (zod-schema-adapter, zod-openapi-plugin) |
| pnpm-workspace.yaml | Updated catalog versions for @types/node, eslint, tsdown, and vitest |
| pnpm-lock.yaml | Comprehensive lockfile update reflecting all dependency changes |
| packages/zod-schema-adapter/* | Deleted entire package directory and all associated files |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
.changeset/v0.4.0-release.md (1)
10-20: Consider expanding the description for clarity on migration path.The changeset content effectively lists the dependency updates and the migration from zod-based to std-schema-based packages. However, it could be more explicit about the user-facing impact and any migration steps required for consumers, especially if this is a breaking change.
Consider adding a brief note about how users should migrate if they were using the old zod-based packages, or confirming that the new std-schema equivalents provide a compatible API.
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (71)
.changeset/v0.4.0-release.md.cursor/commands/commit.md.cursor/commands/create-pr.md.cursor/rules/git.mdcmise.tomlpackage.jsonpackages/eslint-config/package.jsonpackages/example/package.jsonpackages/kori/package.jsonpackages/nodejs-server/package.jsonpackages/openapi-plugin/package.jsonpackages/openapi-swagger-ui-plugin/package.jsonpackages/openapi-swagger-ui-plugin/src/assets/hashes.tspackages/openapi-swagger-ui-plugin/src/assets/swagger-ui-bundle-js.tspackages/openapi-swagger-ui-plugin/src/assets/swagger-ui-css.tspackages/openapi-swagger-ui-plugin/src/assets/swagger-ui-standalone-preset-js.tspackages/script/package.jsonpackages/std-schema-adapter/package.jsonpackages/std-schema-openapi-plugin/package.jsonpackages/zod-openapi-plugin/CHANGELOG.mdpackages/zod-openapi-plugin/README.mdpackages/zod-openapi-plugin/eslint.config.jspackages/zod-openapi-plugin/package.jsonpackages/zod-openapi-plugin/src/index.tspackages/zod-openapi-plugin/src/version.tspackages/zod-openapi-plugin/src/zod-openapi-plugin.tspackages/zod-openapi-plugin/src/zod-schema-converter.tspackages/zod-openapi-plugin/tests/placeholder.test.tspackages/zod-openapi-plugin/tsconfig.build.jsonpackages/zod-openapi-plugin/tsconfig.jsonpackages/zod-openapi-plugin/tsdown.config.jspackages/zod-schema-adapter/CHANGELOG.mdpackages/zod-schema-adapter/README.mdpackages/zod-schema-adapter/eslint.config.jspackages/zod-schema-adapter/package.jsonpackages/zod-schema-adapter/src/index.tspackages/zod-schema-adapter/src/util/index.tspackages/zod-schema-adapter/src/util/is-zod-type.tspackages/zod-schema-adapter/src/zod-enable-validation/enable-zod-request-and-response-validation.tspackages/zod-schema-adapter/src/zod-enable-validation/enable-zod-request-validation.tspackages/zod-schema-adapter/src/zod-enable-validation/enable-zod-response-validation.tspackages/zod-schema-adapter/src/zod-enable-validation/index.tspackages/zod-schema-adapter/src/zod-request-schema/body-content.tspackages/zod-schema-adapter/src/zod-request-schema/body-transformer.tspackages/zod-schema-adapter/src/zod-request-schema/index.tspackages/zod-schema-adapter/src/zod-request-schema/schema.tspackages/zod-schema-adapter/src/zod-response-schema/entry-content.tspackages/zod-schema-adapter/src/zod-response-schema/entry-transformer.tspackages/zod-schema-adapter/src/zod-response-schema/entry.tspackages/zod-schema-adapter/src/zod-response-schema/index.tspackages/zod-schema-adapter/src/zod-response-schema/schema.tspackages/zod-schema-adapter/src/zod-schema/index.tspackages/zod-schema-adapter/src/zod-schema/zod-schema-provider.tspackages/zod-schema-adapter/src/zod-schema/zod-schema.tspackages/zod-schema-adapter/src/zod-validator/index.tspackages/zod-schema-adapter/src/zod-validator/zod-failure.tspackages/zod-schema-adapter/src/zod-validator/zod-validator.tspackages/zod-schema-adapter/tests/integration/full-validation-flow.test.tspackages/zod-schema-adapter/tests/integration/request-validation-flow.test.tspackages/zod-schema-adapter/tests/integration/response-validation-flow.test.tspackages/zod-schema-adapter/tests/util/is-zod-type.test.tspackages/zod-schema-adapter/tests/zod-request-schema/zod-request-schema.test.tspackages/zod-schema-adapter/tests/zod-response-schema/zod-response-schema.test.tspackages/zod-schema-adapter/tests/zod-schema/zod-schema.test.tspackages/zod-schema-adapter/tests/zod-validator/zod-failure.test.tspackages/zod-schema-adapter/tests/zod-validator/zod-validator.test.tspackages/zod-schema-adapter/tsconfig.build.jsonpackages/zod-schema-adapter/tsconfig.jsonpackages/zod-schema-adapter/tsdown.config.jspnpm-workspace.yamltsconfig.json
💤 Files with no reviewable changes (49)
- packages/zod-schema-adapter/src/util/index.ts
- packages/zod-openapi-plugin/tsconfig.json
- packages/zod-schema-adapter/src/zod-schema/index.ts
- packages/zod-schema-adapter/tests/zod-response-schema/zod-response-schema.test.ts
- packages/zod-schema-adapter/src/zod-schema/zod-schema-provider.ts
- packages/zod-schema-adapter/src/zod-response-schema/entry.ts
- packages/zod-openapi-plugin/src/index.ts
- packages/zod-schema-adapter/src/zod-enable-validation/index.ts
- packages/zod-schema-adapter/tests/zod-validator/zod-validator.test.ts
- packages/zod-openapi-plugin/src/version.ts
- packages/zod-schema-adapter/tests/integration/request-validation-flow.test.ts
- packages/zod-schema-adapter/README.md
- packages/zod-schema-adapter/src/zod-enable-validation/enable-zod-request-validation.ts
- packages/zod-openapi-plugin/tsdown.config.js
- .cursor/rules/git.mdc
- packages/zod-schema-adapter/src/zod-request-schema/index.ts
- packages/zod-openapi-plugin/src/zod-schema-converter.ts
- packages/zod-schema-adapter/tests/zod-request-schema/zod-request-schema.test.ts
- packages/zod-schema-adapter/src/zod-enable-validation/enable-zod-response-validation.ts
- packages/zod-schema-adapter/tests/zod-schema/zod-schema.test.ts
- packages/zod-schema-adapter/src/zod-response-schema/index.ts
- packages/zod-schema-adapter/tsconfig.json
- packages/zod-schema-adapter/src/util/is-zod-type.ts
- packages/zod-schema-adapter/eslint.config.js
- packages/zod-schema-adapter/src/zod-response-schema/entry-content.ts
- packages/zod-schema-adapter/src/zod-validator/zod-failure.ts
- packages/zod-schema-adapter/src/index.ts
- packages/zod-schema-adapter/src/zod-validator/index.ts
- packages/zod-schema-adapter/tests/util/is-zod-type.test.ts
- packages/zod-schema-adapter/src/zod-response-schema/schema.ts
- packages/zod-schema-adapter/tests/integration/full-validation-flow.test.ts
- packages/zod-openapi-plugin/README.md
- packages/zod-schema-adapter/src/zod-enable-validation/enable-zod-request-and-response-validation.ts
- packages/zod-openapi-plugin/package.json
- packages/zod-schema-adapter/tsconfig.build.json
- packages/zod-schema-adapter/src/zod-request-schema/body-content.ts
- packages/zod-schema-adapter/src/zod-response-schema/entry-transformer.ts
- packages/zod-schema-adapter/tsdown.config.js
- packages/zod-openapi-plugin/src/zod-openapi-plugin.ts
- packages/zod-schema-adapter/tests/zod-validator/zod-failure.test.ts
- packages/zod-schema-adapter/src/zod-request-schema/body-transformer.ts
- packages/zod-openapi-plugin/tsconfig.build.json
- packages/zod-schema-adapter/src/zod-request-schema/schema.ts
- packages/zod-openapi-plugin/eslint.config.js
- packages/zod-schema-adapter/src/zod-schema/zod-schema.ts
- packages/zod-schema-adapter/src/zod-validator/zod-validator.ts
- packages/zod-schema-adapter/package.json
- packages/zod-schema-adapter/tests/integration/response-validation-flow.test.ts
- packages/zod-openapi-plugin/tests/placeholder.test.ts
🧰 Additional context used
📓 Path-based instructions (4)
.changeset/*.md
📄 CodeRabbit inference engine (.cursor/rules/changeset.mdc)
.changeset/*.md: Changeset files should be created in.changeset/[descriptive-name].mdformat with frontmatter specifying package name and version type (patch/minor/major)
Changeset file frontmatter should include the package name (e.g., '@korix/cors-plugin') and semantic version type (patch, minor, or major) based on the nature of the change
Changeset file content should include a clear, English-language description of the change that focuses on the difference relative to the original baseline
Use semantic versioning strategy for changeset operations: use 'patch' for bug fixes, 'minor' for backward-compatible new features, and 'major' for breaking changes
When creating changesets, focus on describing the difference relative to the original baseline, not just the current working changes
Files:
.changeset/v0.4.0-release.md
**/*.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/coding.mdc)
**/*.{ts,tsx}: Always usetypemodifier for type imports in TypeScript
Use function declarations for framework public APIs in TypeScript
Avoid arrow functions for public APIs in TypeScript
Prefertypeoverinterfacefor type definitions in TypeScript
Useneveras default type parameter instead of{}in TypeScript
Do not usereadonlymodifier in type definitions, class properties, or object properties
Keep related types together in the same file
Use 'Default' suffix for permissive/wildcard generic defaults (e.g.,KoriSchemaDefault,KoriRequestSchemaDefault)
Use 'Base' suffix for fixed core compositions with framework core types bound (e.g.,KoriHandlerContextBase,KoriInstanceContextBase)
**/*.{ts,tsx}: Include @template descriptions for type parameters in JSDoc for public APIs
Document the purpose and constraints of type definitions in JSDoc - explain what the type represents and any limitations or special behaviors
Explain branded types in JSDoc by describing their purpose as branded objects and how they can be extended
Files:
packages/openapi-swagger-ui-plugin/src/assets/hashes.ts
**/*.{ts,js,tsx,jsx}
📄 CodeRabbit inference engine (.cursor/rules/coding.mdc)
**/*.{ts,js,tsx,jsx}: Always include.jsextension in import paths for ESM compatibility
Export public APIs at the end of the file
Use 'Plugin' instead of 'Middleware' in naming and APIs
Avoid 'use' prefix for adding plugins in APIs and code
Use camelCase for function names, variable names, and property names
Treat abbreviations as regular words in camelCase (API → Api, UI → Ui, URL → Url, HTTP → Http)
Plugin function names should follow the pattern<name>Pluginin camelCase
Use ESM (ECMAScript Modules) format for module system
Prefer functions over classes in architecture
Use composition over inheritance in architecture
Avoid using the 'this' keyword in code
Source code files (.ts, .js, .tsx, .jsx) must contain only ASCII characters; non-ASCII characters (emojis, Japanese, etc.) are prohibited
Files:
packages/openapi-swagger-ui-plugin/src/assets/hashes.ts
**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (.cursor/rules/tsdoc.mdc)
**/*.{ts,tsx,js,jsx}: Write comments to explain WHY (not WHAT) - focus on the reasoning behind the code, not what the code does
Don't repeat what's obvious from function names in comments
Use minimal comments for internal implementation details
Write documentation from the user's perspective, not the implementation perspective - focus on what the API does for users, when to use it, inputs/outputs rather than internal implementation details
Include @param descriptions for all function parameters in JSDoc for public APIs
Include @returns descriptions for return values in JSDoc for public APIs
Include @example usage examples in JSDoc when the usage is not obvious from function signature - recommended for complex APIs with multiple options, chaining methods, non-obvious patterns, or common misconceptions
Highlight important details in JSDoc: performance reasons (mutation, caching), execution order (LIFO, defer), and side effects (state changes, logging)
Use @internal JSDoc tag only for exported members that are internal implementation details - do not use for non-exported constants, functions, or types
When using @internal, provide only one-line explanations for complex logic if needed
Use @packageInternal JSDoc tag for internal API that may be re-exported by folder-level index.ts files but must not be re-exported by the package public barrel (src/index.ts)
Mark test exports with @internal tag and add comment 'Exported for testing purposes only'
Comments are not needed for simple wrapper functions, functions with obvious behavior from types, standard getters/setters, or self-evident utility functions
Files:
packages/openapi-swagger-ui-plugin/src/assets/hashes.ts
🧠 Learnings (11)
📚 Learning: 2025-11-29T04:41:59.248Z
Learnt from: CR
Repo: bufferings/kori PR: 0
File: .cursor/rules/coding.mdc:0-0
Timestamp: 2025-11-29T04:41:59.248Z
Learning: Applies to **/*.{ts,tsx} : Use function declarations for framework public APIs in TypeScript
Applied to files:
tsconfig.json
📚 Learning: 2025-11-29T04:41:59.248Z
Learnt from: CR
Repo: bufferings/kori PR: 0
File: .cursor/rules/coding.mdc:0-0
Timestamp: 2025-11-29T04:41:59.248Z
Learning: Applies to **/*.{ts,js,tsx,jsx} : Avoid 'use' prefix for adding plugins in APIs and code
Applied to files:
tsconfig.json
📚 Learning: 2025-11-29T04:42:38.592Z
Learnt from: CR
Repo: bufferings/kori PR: 0
File: .cursor/rules/test.mdc:0-0
Timestamp: 2025-11-29T04:42:38.592Z
Learning: Applies to **/tests/**/*.ts
**/*.test.ts
**/*.spec.ts : Always explicitly import test utilities (describe, test, expect, vi, expectTypeOf) without relying on vitest globals configuration
Applied to files:
packages/eslint-config/package.jsonpackages/script/package.json
📚 Learning: 2025-11-29T04:42:38.592Z
Learnt from: CR
Repo: bufferings/kori PR: 0
File: .cursor/rules/test.mdc:0-0
Timestamp: 2025-11-29T04:42:38.592Z
Learning: Applies to **/tests/**/*.ts
**/*.test.ts
**/*.spec.ts : Use ESM only in tests with .js extensions included in imports
Applied to files:
packages/eslint-config/package.json
📚 Learning: 2025-11-29T04:42:38.592Z
Learnt from: CR
Repo: bufferings/kori PR: 0
File: .cursor/rules/test.mdc:0-0
Timestamp: 2025-11-29T04:42:38.592Z
Learning: Applies to **/tests/**/*.ts
**/*.test.ts
**/*.spec.ts : Use type imports for types in test files
Applied to files:
packages/eslint-config/package.json
📚 Learning: 2025-11-29T04:41:45.858Z
Learnt from: CR
Repo: bufferings/kori PR: 0
File: .cursor/rules/changeset.mdc:0-0
Timestamp: 2025-11-29T04:41:45.858Z
Learning: Applies to .changeset/*.md : Changeset file frontmatter should include the package name (e.g., 'korix/cors-plugin') and semantic version type (patch, minor, or major) based on the nature of the change
Applied to files:
.changeset/v0.4.0-release.mdmise.tomlpackage.json
📚 Learning: 2025-11-29T04:41:45.858Z
Learnt from: CR
Repo: bufferings/kori PR: 0
File: .cursor/rules/changeset.mdc:0-0
Timestamp: 2025-11-29T04:41:45.858Z
Learning: Applies to .changeset/*.md : Use semantic versioning strategy for changeset operations: use 'patch' for bug fixes, 'minor' for backward-compatible new features, and 'major' for breaking changes
Applied to files:
.changeset/v0.4.0-release.md
📚 Learning: 2025-11-29T04:41:45.858Z
Learnt from: CR
Repo: bufferings/kori PR: 0
File: .cursor/rules/changeset.mdc:0-0
Timestamp: 2025-11-29T04:41:45.858Z
Learning: Applies to .changeset/*.md : Changeset files should be created in `.changeset/[descriptive-name].md` format with frontmatter specifying package name and version type (patch/minor/major)
Applied to files:
.changeset/v0.4.0-release.md
📚 Learning: 2025-11-29T04:42:13.300Z
Learnt from: CR
Repo: bufferings/kori PR: 0
File: .cursor/rules/git.mdc:0-0
Timestamp: 2025-11-29T04:42:13.300Z
Learning: When creating PRs with GitHub CLI that have long descriptions, create a temporary file for the description and use `gh pr create --body-file temp_file.md` instead of passing the description as command line arguments to avoid zsh misinterpreting special characters
Applied to files:
.cursor/commands/create-pr.md
📚 Learning: 2025-11-29T04:42:13.300Z
Learnt from: CR
Repo: bufferings/kori PR: 0
File: .cursor/rules/git.mdc:0-0
Timestamp: 2025-11-29T04:42:13.300Z
Learning: Use imperative mood in commit messages (e.g., 'Fix bug' not 'Fixed bug' or 'Fixes bug')
Applied to files:
.cursor/commands/commit.md
📚 Learning: 2025-11-29T04:42:13.300Z
Learnt from: CR
Repo: bufferings/kori PR: 0
File: .cursor/rules/git.mdc:0-0
Timestamp: 2025-11-29T04:42:13.300Z
Learning: Write commit messages in English for international collaboration
Applied to files:
.cursor/commands/commit.md
🪛 markdownlint-cli2 (0.18.1)
.cursor/commands/commit.md
36-36: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
54-54: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
🔇 Additional comments (20)
.cursor/commands/create-pr.md (1)
1-47: LGTM! Clear and comprehensive PR creation workflow.The documentation provides a well-structured step-by-step workflow for creating pull requests. The use of
--body-filefor the PR description aligns with best practices to avoid shell escaping issues, consistent with the learnings from previous feedback..cursor/commands/commit.md (1)
1-62: LGTM! Clear commit workflow documentation.The documentation provides a comprehensive step-by-step workflow for committing changes with well-defined commit message format rules. The guidelines follow best practices including imperative mood, ASCII characters, and appropriate line length limits.
Note: The static analysis hints about missing language specifiers for the code blocks at lines 36-40 and 54-62 are false positives—these blocks demonstrate commit message format, not programming code, so language specifiers are not applicable.
packages/openapi-swagger-ui-plugin/src/assets/hashes.ts (1)
3-5: LGTM! Auto-generated hashes updated for Swagger UI 5.31.0.The asset hashes have been correctly regenerated to match the updated swagger-ui-dist version (5.29.4 → 5.31.0). Since this is an auto-generated file, the changes are expected and appropriate.
package.json (1)
25-25: All devDependency versions are valid and exist on the npm registry.@changesets/cli@2.29.8, prettier@3.7.4, turbo@2.7.2, and vitepress@1.6.4 have been verified as legitimate versions. No issues found.
packages/example/package.json (2)
34-35: All specified dependency versions exist on npm and are valid.Verified: openapi3-ts@4.5.0, zod@4.2.1, pino-pretty@13.1.3, and tsx@4.21.0 are all published releases.
40-40: Cross-env 10.1.0 upgrade is compatible with CLI usage.The dev scripts use cross-env only as a CLI tool in npm scripts, which remains fully supported and unchanged in v10. No breaking changes affect how it's invoked here. However, note that cross-env 10.1.0 requires Node.js >= 20; verify your project's Node.js version constraint supports this requirement.
Likely an incorrect or invalid review comment.
packages/eslint-config/package.json (1)
59-62: All ESLint tooling versions are compatible.Verification confirms that @eslint/js@9.39.2 and all typescript-eslint@8.51.0 packages exist on npm and are compatible with each other. The peerDependencies in package.json (eslint ^9.39.0 and typescript ^5.9.0) satisfy the requirements of typescript-eslint@8.51.0.
packages/std-schema-openapi-plugin/package.json (1)
61-61: Dependencies verified and compatible. Both openapi3-ts@4.5.0 and zod@4.2.1 exist on npm at their latest versions with no known security vulnerabilities or compatibility conflicts.packages/script/package.json (1)
41-42: No concerns. Bothexeca@9.6.1andp-limit@7.2.0are valid versions currently available on npm, and neither has known security vulnerabilities.tsconfig.json (1)
13-13: LGTM! TypeScript references updated correctly.The TypeScript project references have been correctly updated to reflect the migration from Zod-based packages to std-schema equivalents. The std-schema-openapi-plugin reference is properly included.
pnpm-workspace.yaml (2)
5-5: @types/node downgrade aligns with Node.js 20 requirement.The @types/node has been intentionally downgraded from 22.12.0 to 20.19.27 to match the minimum Node.js version requirement (>=20.0.0) and the specific Node.js version 20.19.6 configured in mise.toml. This ensures type definitions are consistent with the actual runtime version.
6-6: All catalog dependency versions verified and correctly classified.✓ eslint 9.39.2 exists (update from 9.39.1 — patch)
✓ tsdown 0.18.3 exists (update from 0.16.6 — minor)
✓ vitest 4.0.16 exists (update from 4.0.13 — patch)Review the changelogs for these updates to understand any behavioral changes.
mise.toml (2)
2-2: LGTM! Lefthook installation added to postinstall hook.The postinstall hook now includes "lefthook install" after enabling corepack. This aligns with the PR objective to manage lefthook via mise instead of package.json, ensuring the Git hooks are properly installed during setup.
8-9: Tool versions are available and properly aligned.The updated tool versions in mise.toml are confirmed:
- lefthook 2.0.13 (released December 26, 2025)
- node 20.19.6 (released November 25, 2025 as LTS)
The Node.js version 20.19.6 correctly aligns with @types/node 20.19.27 in pnpm-workspace.yaml. No known critical issues in the release notes for either tool.
packages/nodejs-server/package.json (1)
58-58: @hono/node-server 1.19.7 exists in the npm registry.Version 1.19.7 is published and valid.
packages/openapi-plugin/package.json (1)
60-60: openapi3-ts 4.5.0 is compatible with no breaking changes. Version 4.5.0 exists on npm and the changelog shows only additive changes: updated libraries, added missing PathItems component, and extended $ref support in OpenAPI 3.1 SchemaObjects. The version bump is safe to proceed.packages/std-schema-adapter/package.json (1)
59-59: Both @standard-schema/spec 1.1.0 and zod 4.2.1 are published in npm registry with no breaking changes:
- @standard-schema/spec 1.1.0 is a minor bump with no breaking changes (project policy guarantees breaking changes only in major versions)
- zod 4.2.1 is a patch release with no new breaking changes
These updates are safe and compatible.
packages/openapi-swagger-ui-plugin/package.json (1)
77-77: swagger-ui-dist 5.31.0 is available and safe to use.Version 5.31.0 exists in npm registry (released 2025-12-11). The main feature is dark mode support. No breaking changes or security vulnerabilities are reported. Note: version 5.30.0 also exists in the registry; the upgrade from 5.29.4 to 5.31.0 does not represent a skipped unavailable version.
packages/kori/package.json (1)
58-58: Hono 4.11.3 upgrade is compatible; focus testing on TypeScript types and specific middleware.Verified that Hono 4.11.3 exists and contains no breaking changes from 4.9.8. The upgrade includes TypeScript middleware type improvements (v4.10.0), CORS security fixes (v4.10.3), and client enhancements (v4.11.0). Test areas that warrant attention:
- TypeScript middleware typing changes in v4.10.0 (may require type adjustments)
- CORS middleware if in use (security fix applied)
- Bearer-auth middleware if used (some option names are deprecated but still functional)
.changeset/v0.4.0-release.md (1)
1-8: Verify semantic versioning for package removals.All packages are marked as 'minor', but the changeset mentions removing zod-schema-adapter and zod-openapi-plugin packages (line 19). If these were part of the public API or exports of any of these packages, their removal is a breaking change and should be marked as 'major' per semantic versioning guidelines.
Based on learnings and coding guidelines, please clarify:
- Were zod-schema-adapter and zod-openapi-plugin part of the public API/exports of any of the packages listed in the frontmatter?
- If yes, the version type should be 'major' rather than 'minor' for those packages.
- If they were internal implementation details only, 'minor' is appropriate.
Alternatively, if you intend to treat this as a pre-1.0 breaking change under a unified minor bump (0.3.x → 0.4.0), please document this intention in the changeset content for clarity.
Summary
Prepare for v0.4.0 release with dependency updates and cleanup.
Changes
Package Changes
zod-schema-adapterandzod-openapi-pluginpackagesstd-schema-adapterandstd-schema-openapi-plugininsteadDependency Updates
Tooling
Cursor Commands
.cursor/commands/commit.mdfor commit workflow.cursor/commands/create-pr.mdfor PR creation workflow.cursor/rules/git.mdc(content moved to commands)Summary by CodeRabbit
Chores
Documentation
✏️ Tip: You can customize this high-level summary in your review settings.