intent(test-coverage): normalizeObjectNode is the load-bearing workaround for @valibot/to-json-schema's output gaps (missing additionalProperties:false, noisy empty required arrays). A bug in its tree walk would silently break the published repomix.config.json IntelliSense schema. Extract to its own module and pin the behavior: adding/respecting additionalProperties, stripping empty required, recursing through properties / anyOf / oneOf / items, handling null and primitives
intent(unwrap-limitation): document that the `.default`-is-an-object heuristic in configLoad would still truncate a pathological CJS module of shape `{ default: {...}, otherKey: ... }` — not a known user pattern since RepomixConfig has no `default` field, but worth calling out so future readers don't have to re-derive it
intent(mutation-callout): note that `normalizeObjectNode` mutates the JSON-schema tree in place — the return-type hint (`void`) already implies it, but a one-line comment saves a future reader from tracing call sites
intent(error-handle): drop the instanceof Error guard in rethrowValidationErrorIfSchemaError so ValiError / ZodError round-tripped through a worker (plain { name, message, issues }) is still recognized — aligns with isError / isRepomixError elsewhere in the file
intent(schema-parity): restore splitOutput's upper bound (Number.MAX_SAFE_INTEGER) in the generated JSON schema so editor hints match the previous zod output; also strip the empty required:[] arrays that @valibot/to-json-schema emits on every object node
intent(esm-unwrap): only unwrap jiti's .default when it's an object, preserving a CJS config that legitimately exports { default: 'plain', ...rest }; plain Symbol.toStringTag === 'Module' was too narrow — jiti returns non-Module namespace wrappers for .ts / .mts files
intent(test-coverage): add tests/shared/errorHandle.test.ts covering the Zod + Valibot + worker-serialized paths through rethrowValidationErrorIfSchemaError; tighten the default-schema assertion in configSchema.test.ts from /expected|invalid/i to toThrow(v.ValiError) + targeted message pattern
decision(path-segment-fallback): return '' for unknown object-shaped path items instead of falling into String(segment) → "[object Object]"; defensive, non-breaking
intent(schema-generation): website-generate-schema silently threw after the zod→valibot migration because generateSchema.ts still called z.toJSONSchema on a valibot schema — the script's `.catch(console.error)` was hiding the TypeError in CI
decision(schema-converter): @valibot/to-json-schema over maintaining a parallel zod schema — keeps the source of truth in src/config/configSchema.ts as the only schema definition
constraint(vscode-intellisense): must preserve additionalProperties: false on generated objects so editors still flag typos in repomix.config.json — @valibot/to-json-schema omits it, so generateSchema now walks the tree to add it
learned(valibot-json-schema-gap): v.object strips unknown keys at runtime but the converter does not emit additionalProperties: false. Post-processing is the lightest-touch fix; switching to v.strictObject would make runtime parsing throw on extra keys, which is a breaking change for existing users
Replaced zod-to-json-schema with Zod v4's native toJSONSchema() method
for generating JSON Schema from Zod schemas. This eliminates the need
for an external dependency and leverages Zod v4's new built-in feature.
Changes:
- Updated generateSchema.ts to use z.toJSONSchema() with draft-7 target
- Removed direct dependency on zod-to-json-schema (still exists via MCP SDK)
- Simplified the schema generation process
The generated schema remains compatible with the existing format and
all tooling that depends on it.
Kazuki Yamada
Devin AI
Kazuki Yamada