You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
#### Refactor error system to use normalized `EnvIssue` and add `{ safe: true }` API
6
+
7
+
Introduce a unified `EnvIssue` type for programmatic access to validation issues via `ArkEnvError.issues`, and add the non-throwing `{ safe: true }` configuration option to `arkenv`.
8
+
9
+
Error messages now use ANSI colors instead of a bullet-point prefix:
10
+
11
+
```diff
12
+
- - [PORT] must be a valid port number (was "invalid-port")
13
+
+ PORT must be a valid port number (was "invalid-port")
14
+
```
15
+
16
+
Note: Header (red), variable path (yellow), and received value (cyan) are now styled with ANSI escape codes. Update any test suites asserting on exact error text.
17
+
18
+
**BREAKING CHANGE**: `ValidationIssue` and `formatInternalErrors` removed. Use `EnvIssue` and `formatIssues` instead.
The `safe: true` option is purposefully omitted from the configuration options of framework integrations (like `@arkenv/vite-plugin`, `@arkenv/nextjs`, etc.).
114
+
115
+
Framework integrations rely on injecting the raw, validated environment variables into the build process. If `safe: true` were enabled, a validation failure would result in the plugin silently injecting the `{ success: false, issues }` wrapper object into your application bundle instead of crashing the build, leading to broken downstream behavior.
116
+
117
+
If you need to handle validation failures programmatically without failing the build, you should invoke `arkenv()` manually rather than using an automated bundler plugin.
Copy file name to clipboardExpand all lines: docs/CONTEXT.md
+14-1Lines changed: 14 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -176,6 +176,15 @@ pnpm run test:e2e # E2E tests
176
176
- Run `pnpm release` after merging PRs to publish packages
177
177
- Only packages in `packages/` are published to npm
178
178
179
+
## Design Decisions
180
+
181
+
**Split Parsing Engines (ArkType vs Standard Schema):**
182
+
183
+
- ArkEnv maintains two distinct parsing engines: `src/arktype/index.ts` and `src/parse-standard.ts`.
184
+
- Despite visual similarities, they are strictly isolated to guarantee the `arkenv/standard` module boundary remains "ArkType-free".
185
+
- Unifying them would force bundlers to trace static imports and drag ArkType into the dependency tree of Standard Schema users, violating the zero-dependency goal.
186
+
- We prioritize optimal tree-shaking, bundle size isolation, and decoupling over dogmatic DRYness.
187
+
179
188
## Domain context
180
189
181
190
**Environment Variable Validation:**
@@ -225,8 +234,12 @@ pnpm run test:e2e # E2E tests
225
234
- Leverages ArkType's `type.infer` and `type.validate` utilities
226
235
- Typesafe environment object returned from `arkenv`
227
236
228
-
**Error Handling:**
237
+
**Error Handling & Vocabulary:**
229
238
239
+
-**Issue vs. Error Distinction**: ArkEnv strictly differentiates between an "Issue" and an "Error".
240
+
-**Issue (`EnvIssue`)**: A single, isolated validation failure on a specific environment variable.
241
+
-**Error (`ArkEnvError`)**: The overarching runtime exception that is thrown when validation fails. It contains an array of `EnvIssue`s.
242
+
- Functions dealing with individual failures should use "Issue" (e.g., `formatIssues`), while functions dealing with the final halting exception should use "Error" (e.g., `ArkEnvError`).
230
243
-`ArkEnvError` extends `Error` and formats ArkType validation errors
231
244
- Errors include variable names and expected types
232
245
- Fail-fast approach: app won't start if validation fails
ArkEnv operates as a zero-dependency environment variable parser. It uses ArkType as its primary validation engine (`arkenv`), while also offering a completely separate entry point (`arkenv/standard`) that leverages Standard Schema 1.0 (for users preferring Zod, Valibot, etc.).
12
+
13
+
During the refactoring to a single core repository with multiple internal exports, a code review raised concerns about code duplication between `src/arktype/index.ts` and `src/parse-standard.ts`. Both files implement similar logic for parsing objects, extracting issue metadata, and formatting validation results. The suggestion was to "aggressively unify or codeshare" these implementations to abide by the DRY (Don't Repeat Yourself) principle.
14
+
15
+
However, sharing utilities across the core ArkType engine and the Standard Schema engine introduces hidden module graph entanglements. Bundlers like Webpack, Rollup, and esbuild often rely on static imports for tree-shaking. A single shared `utils.ts` file imported by both entry points can easily trick the bundler's heuristics into statically tracing the dependency tree back to `arktype`. This would drag the entire 50kb+ ArkType AST engine into the production bundle of users who only wanted to use `arkenv/standard` with Zod.
16
+
17
+
## Decision
18
+
19
+
We intentionally duplicate parsing, formatting, and issue-mapping logic across the `arktype` and `standard` engine implementations to maintain an airtight module boundary. **Bundle isolation strictly trumps DRYness across core/standard boundaries.**
20
+
21
+
We will not create shared abstractions or utility files that bridge these two domains. The small maintenance cost of duplicated internal logic is a worthwhile trade-off to guarantee that `arkenv/standard` users never incur a bundle size penalty from ArkType.
22
+
23
+
## Consequences
24
+
25
+
- The footprint of `@arkenv/standard` remains strictly minimal and fully decoupled from ArkType.
26
+
- Contributors must be aware that fixing a bug in the error extraction logic for ArkType may require a mirrored fix in the Standard Schema logic.
27
+
- Future code reviews raising concerns about DRYness between these files should be directed to this ADR.
0 commit comments