Summary
Currently, neither @orval/zod nor @orval/effect declare their respective runtime schema libraries (zod and effect) as peerDependencies in their package.json manifests — they rely on the consuming app to have the library installed.
This is a repo-wide convention question: should all @orval/* packages that wrap a user-facing library declare it explicitly as a peerDependency?
Pros of adding explicit peerDependencies:
- Package managers (npm, pnpm, yarn) will warn users if the peer is missing or the version is incompatible.
- Signals the version contract clearly to consumers.
- Follows standard ecosystem practice for plugin/wrapper packages.
Current state:
packages/zod/package.json — zod is not listed under peerDependencies.packages/effect/package.json — effect is not listed under peerDependencies (matching @orval/zod convention).
Suggested action
Decide on a repo-wide convention and apply it consistently to all @orval/* packages that wrap a user-installable peer library. If the decision is to add peer deps, packages/zod/package.json and packages/effect/package.json (and potentially others) should be updated together.
References
Summary
Currently, neither
@orval/zodnor@orval/effectdeclare their respective runtime schema libraries (zodandeffect) aspeerDependenciesin theirpackage.jsonmanifests — they rely on the consuming app to have the library installed.This is a repo-wide convention question: should all
@orval/*packages that wrap a user-facing library declare it explicitly as apeerDependency?Pros of adding explicit
peerDependencies:Current state:
packages/zod/package.json—zodis not listed underpeerDependencies.packages/effect/package.json—effectis not listed underpeerDependencies(matching@orval/zodconvention).Suggested action
Decide on a repo-wide convention and apply it consistently to all
@orval/*packages that wrap a user-installable peer library. If the decision is to add peer deps,packages/zod/package.jsonandpackages/effect/package.json(and potentially others) should be updated together.References