Plugin distribution strategy

[yamcodes]

Status

Proposed

Context

ArkEnv provides framework integrations via @arkenv/vite-plugin and @arkenv/bun-plugin.
Current internal packages and dependency boundaries make bundling, optional peer deps, and installation ergonomics harder than necessary.

Decision

Framework plugins are thin wrappers around arkenv.

arkenv (core)
 ├─ @arkenv/vite-plugin
 └─ @arkenv/bun-plugin

Plugins depend on arkenv and delegate all validation logic to it.

Installation model

Plugins provide single-install ergonomics:

pnpm add @arkenv/vite-plugin

• arkenv is a direct dependency of the plugin
• Users do not need to install arkenv manually
• Optional peer deps (for example arktype) remain handled by arkenv

This matches ecosystem expectations (Vite, Bun).

Shared code and types

• Shared helpers and types live in arkenv
• No internal workspace packages (for example @repo/types, @repo/scope)
• Internal-only exports are allowed and marked with @internal
• Plugins import from arkenv, never from private paths

ArkType isolation

• ArkType-specific logic remains inside arkenv
• Loaded lazily and only when validator: "arktype" is used
• Plugins are ArkType-agnostic

Consequences

Pros

• Clear dependency graph
• Simpler bundling and testing
• Idiomatic plugin usage
• Fewer moving parts before v1

Cons

• Some internal helpers are technically exported
• Requires discipline to keep internals undocumented