@rawan-temo/prisma-zod-generator 3.3.1-config-coercion.0

package/website/docs/config/modes.md

@@ -0,0 +1,48 @@
+---
+id: modes
+title: Generation Modes
+---
+
+| Mode    | Models default              | Variants default                        | Operations                  | Notes                                                                     |
+| ------- | --------------------------- | --------------------------------------- | --------------------------- | ------------------------------------------------------------------------- |
+| full    | all enabled                 | all enabled                             | all Prisma ops              | Richest output                                                            |
+| minimal | all enabled unless disabled | input & pure enabled (result often off) | Restricted core CRUD + find | Prunes complex nested inputs, disables select/include; model selection behaves exactly like full mode |
+| custom  | all enabled unless disabled | respect `variants.*.enabled`            | all unless filtered         | Explicit control                                                          |
+
+Minimal mode specifics:
+
+- **Does not disable models**: every model is generated unless you set `models.<Name>.enabled = false`. Minimal mode narrows the *operation* set and prunes nested input objects; it never blanket-disables models.
+- Forces `select/include` disabled even if flags set.
+- Applies `MINIMAL_OPERATIONS` for models that do not specify their own `operations`. The built-in set is `findMany`, `findUnique`, `findFirst`, `create`, `update`, `delete`.
+- Skips many heavy nested input object schemas (allow-list basics).
+- **Create operations use `UncheckedCreateInput` only**: Blocks regular `*CreateInput` schemas that require complex nested relations, favoring simple foreign key-based `*UncheckedCreateInput` schemas.
+- **Update operations support both variants**: Allows both `*UpdateInput` and `*UncheckedUpdateInput` for flexibility.
+
+### Overriding the minimal operation set
+
+You can replace the built-in allow-list with your own by adding a top-level `minimalOperations` array of canonical operation names:
+
+```json
+{
+  "mode": "minimal",
+  "minimalOperations": ["findMany", "findUnique", "create", "createMany", "update"]
+}
+```
+
+The array replaces the built-in allow-list wholesale for models you have not listed under `models` — a model with its own `operations` array always wins, and a model listed without one still receives `MINIMAL_OPERATIONS`. Legacy aliases (`createOne`, `updateOne`, `deleteOne`, `upsertOne`) are normalised to their canonical names before the check, so only the canonical form is needed here. Including `create` or `createMany` additionally unblocks the `*CreateManyInput` object schemas that minimal mode otherwise skips as too heavy.
+
+:::note
+`minimalOperations` is an escape hatch rather than part of the per-model filtering contract — it applies globally, unlike `models.*.operations`. It is declared in the config interface and in the published JSON Schema, so `$schema` completion and `ConfigurationValidator` both accept it.
+:::
+
+## Emission Heuristics
+
+| Condition                                                              | Effect                                                            |
+| ---------------------------------------------------------------------- | ----------------------------------------------------------------- |
+| `pureModels=true` AND all `variants.*.enabled=false` AND `mode=custom` | Pure-models-only (emit only pure model schemas)                   |
+| `pureModels=true` AND only `variants.pure.enabled=true`                | Pure-variant-only (skip CRUD/input/result schemas)                |
+| `emit.results=false`                                                   | Internally sets `variants.result.enabled=false` before generation |
+| `useMultipleFiles=false`                                               | Single-file bundle; directory cleanup after flush                 |
+| `mode=minimal`                                                         | Suppresses select/include + prunes deep input objects             |
+
+Explicit `emit.*` booleans, when provided, override heuristics for that category (except minimal’s enforced suppressions).

package/website/docs/config/naming.md

@@ -0,0 +1,177 @@
+---
+id: naming
+title: Naming & Presets
+---
+
+## Pure Model Naming
+
+Pure model naming resolved by `resolvePureModelNaming`:
+
+### Presets:
+
+- `default`: `{Model}.schema.ts`, export `{Model}Schema` / type `{Model}Type`.
+- `zod-prisma`: same as default + legacy aliases.
+- `zod-prisma-types`: file `{Model}.schema.ts`, export `{Model}` (no suffixes), legacy aliases.
+- `legacy-model-suffix`: `{Model}.model.ts`, export `{Model}Model`.
+
+### Overrides via `naming.pureModel`:
+
+- `filePattern` (`{Model}.schema.ts`, supports tokens `{Model}{SchemaSuffix}` etc.)
+- `schemaSuffix`, `typeSuffix`, `exportNamePattern`, `legacyAliases`.
+
+Relation import rewriting adapts when using `.model` pattern.
+
+## Schema Naming (CRUD Operations)
+
+Schema naming resolved by `resolveSchemaNaming`:
+
+### Default Patterns:
+- `filePattern`: `{operation}{Model}.schema.ts`
+- `exportNamePattern`: `{Model}{Operation}Schema`
+
+### Examples:
+- `findManyUser.schema.ts` with export `UserFindManySchema`
+- `createOnePost.schema.ts` with export `PostCreateOneSchema`
+
+### Overrides via `naming.schema`:
+```json
+{
+  "naming": {
+    "schema": {
+      "filePattern": "{kebab}-{operation}-{model}.schema.ts",
+      "exportNamePattern": "{Model}{Operation}ValidationSchema"
+    }
+  }
+}
+```
+
+### ⚠️ Important Pattern Requirements
+
+**Operation Token Required**: Your `filePattern` MUST include an operation token (`{operation}` or `{Operation}`) to avoid file collisions. Without it, all CRUD operations for the same model will overwrite each other, resulting in only the last operation being generated.
+
+**Examples**:
+- ✅ `{kebab}-{operation}-schema.ts` → `user-findMany-schema.ts`, `user-createOne-schema.ts`
+- ✅ `{operation}{Model}.schema.ts` → `findManyUser.schema.ts`, `createOneUser.schema.ts`
+- ❌ `{kebab}-schema.ts` → `user-schema.ts` (all operations overwrite each other!)
+
+**Collision Detection**: The generator will detect filename collisions and throw an error during generation. Always include `{operation}` or `{Operation}` in your pattern.
+
+### Available Tokens:
+- `{Model}`: PascalCase model name (e.g., `User`, `BlogPost`)
+- `{model}`: camelCase model name (e.g., `user`, `blogPost`)
+- `{kebab}`: kebab-case model name (e.g., `user`, `blog-post`)
+- `{Operation}`: PascalCase operation (e.g., `FindMany`, `CreateOne`)
+- `{operation}`: camelCase operation (e.g., `findMany`, `createOne`)
+
+## Input Object Naming
+
+Input object naming resolved by `resolveInputNaming`:
+
+### Default Patterns:
+- `filePattern`: `{InputType}.schema.ts`
+- `exportNamePattern`: `{Model}{InputType}ObjectSchema`
+
+`filePattern` is resolved **relative to the generated `objects/` directory**, so a pattern containing directory segments nests inside it: `inputs/{InputType}.schema.ts` writes to `objects/inputs/UserWhereInput.schema.ts`, not `inputs/UserWhereInput.schema.ts`.
+
+### Examples:
+- `UserWhereInput.schema.ts` with export `UserWhereInputObjectSchema` (written to `objects/UserWhereInput.schema.ts`)
+- `PostCreateInput.schema.ts` with export `PostCreateInputObjectSchema`
+
+### Overrides via `naming.input`:
+```json
+{
+  "naming": {
+    "input": {
+      "filePattern": "{kebab}-{InputType}-input.ts",
+      "exportNamePattern": "{Model}{InputType}"
+    }
+  }
+}
+```
+
+### Available Tokens:
+- `{Model}`: PascalCase model name extracted from input type
+- `{model}`: camelCase model name
+- `{kebab}`: kebab-case model name (e.g., `user`, `blog-post`)
+- `{InputType}`: Full input type name (e.g., `UserWhereInput`, `PostCreateInput`)
+
+### ⚠️ Important Pattern Requirements
+
+**File Pattern Must Include Unique Identifiers**: Your `filePattern` must include tokens that make each input type unique. Without proper uniqueness, multiple input types for the same model will generate identical filenames and overwrite each other.
+
+**Recommended Patterns** (paths shown relative to the generated `objects/` directory):
+- ✅ `{kebab}-{InputType}-input.ts` → `book-BookCreateInput-input.ts`
+- ✅ `{InputType}.schema.ts` → `BookCreateInput.schema.ts`
+- ✅ `inputs/{Model}/{InputType}.ts` → `inputs/Book/CreateInput.ts` (nested under `objects/`; the duplicate `Book` prefix is stripped — see the note below)
+- ❌ `{kebab}-input.ts` → `book-input.ts` (all Book inputs collide!)
+
+:::caution
+**No collision detection for input objects.** Unlike CRUD operation schemas, input object filenames are **not** checked for collisions. Colliding files are silently overwritten and you simply end up missing schemas — no error is raised. Make sure your pattern is unique per input type (keep `{InputType}` in it).
+:::
+
+**Note**: When your pattern includes a model token (`{Model}` or `{model}`) together with `{InputType}`, duplicate model prefixes are automatically stripped for both export names and file names to avoid results like `UserUserWhereInput*`.
+
+## Enum Naming
+
+Enum naming resolved by `resolveEnumNaming`:
+
+### Default Patterns:
+- `filePattern`: `{Enum}.schema.ts`
+- `exportNamePattern`: `{Enum}Schema`
+
+`filePattern` is resolved **relative to the generated `enums/` directory** — do not prefix it with `enums/`. A pattern of `enums/{Enum}.enum.ts` produces `enums/enums/Role.enum.ts` (with imports pointing at the doubled path), which is almost never what you want.
+
+### Examples:
+- `Role.schema.ts` with export `RoleSchema` (written to `enums/Role.schema.ts`)
+- `UserStatus.schema.ts` with export `UserStatusSchema`
+
+### Overrides via `naming.enum`:
+```json
+{
+  "naming": {
+    "enum": {
+      "filePattern": "{Enum}Validator.schema.ts",
+      "exportNamePattern": "{Enum}ValidatorSchema"
+    }
+  }
+}
+```
+
+### Available Tokens:
+- `{Enum}`: PascalCase enum name (e.g., `Role`, `UserStatus`)
+- `{enum}`: camelCase enum name (e.g., `role`, `userStatus`)
+- `{camel}`: camelCase alias for `{enum}` — **in `filePattern` only**. Export-name patterns do not substitute `{camel}`, so it would survive literally in `exportNamePattern`; use `{enum}` there.
+
+## Complete Configuration Example
+
+```json
+{
+  "naming": {
+    "preset": "default",
+    "pureModel": {
+      "filePattern": "{Model}.model.ts",
+      "exportNamePattern": "{Model}Model"
+    },
+    "schema": {
+      "filePattern": "{operation}-{kebab}.schema.ts",
+      "exportNamePattern": "{Model}{Operation}ValidationSchema"
+    },
+    "input": {
+      "filePattern": "inputs/{InputType}.schema.ts",
+      "exportNamePattern": "{InputType}Schema"
+    },
+    "enum": {
+      "filePattern": "{Enum}.enum.ts",
+      "exportNamePattern": "{Enum}EnumSchema"
+    }
+  }
+}
+```
+
+This would generate:
+- Pure models: `models/User.model.ts` → `UserModel`
+- Schemas: `findMany-user.schema.ts` → `UserFindManyValidationSchema`
+- Inputs: `objects/inputs/UserWhereInput.schema.ts` → `UserWhereInputSchema`
+- Enums: `enums/Role.enum.ts` → `RoleEnumSchema`
+
+Remember that `input.filePattern` is relative to `objects/` and `enum.filePattern` is relative to `enums/` — the extra `inputs/` segment above is deliberate, whereas an `enums/` prefix would be doubled.

package/website/docs/config/optional-fields.md

@@ -0,0 +1,193 @@
+---
+id: optional-fields
+title: Optional Field Behavior
+---
+
+The `optionalFieldBehavior` configuration option controls how optional Prisma fields (marked with `?`) are mapped to Zod validation schemas.
+
+:::note
+**Scope.** `optionalFieldBehavior` applies to **pure model schemas** — the `models/` output produced with `pureModels: true`. CRUD input object schemas under `objects/` follow the fixed policy described in [Object Schemas: Optional vs Nullable](#object-schemas-optional-vs-nullable-behavior-note), and variant schemas under `variants/` use their own fixed policy. Neither reads this setting.
+:::
+
+## Configuration Options
+
+| Value               | Zod Output    | TypeScript Type          | Description                                            |
+| ------------------- | ------------- | ------------------------ | ------------------------------------------------------ |
+| `nullish` (default) | `.nullish()`  | `T \| null \| undefined` | Field can be omitted, explicitly null, or have a value |
+| `optional`          | `.optional()` | `T \| undefined`         | Field can be omitted or have a value, but not null     |
+| `nullable`          | `.nullable()` | `T \| null`              | Field must be present but can be null or have a value  |
+
+## Usage
+
+### Generator Block Configuration
+
+Configure directly in your `schema.prisma`:
+
+```prisma
+generator zod {
+  provider = "prisma-zod-generator"
+  optionalFieldBehavior = "optional"
+}
+```
+
+### JSON Configuration
+
+Or in your `zod-generator.config.json`:
+
+```json
+{
+  "optionalFieldBehavior": "nullish"
+}
+```
+
+## Examples
+
+The snippets below show the generated **pure model** schema (`generated/schemas/models/User.schema.ts`). Given this Prisma model:
+
+```prisma
+model User {
+  id    Int     @id @default(autoincrement())
+  email String  @unique
+  name  String?  // Optional field
+  bio   String?  // Optional field
+}
+```
+
+### Nullish Behavior (Default)
+
+```typescript
+// generated/schemas/models/User.schema.ts
+export const UserSchema = z.object({
+  email: z.string(),
+  name: z.string().nullish(),
+  bio: z.string().nullish()
+});
+
+// Valid inputs
+{ email: "test@example.com", name: "John", bio: "Developer" }
+{ email: "test@example.com", name: null, bio: undefined }
+{ email: "test@example.com" } // name and bio omitted
+```
+
+### Optional Behavior
+
+```typescript
+// generated/schemas/models/User.schema.ts
+export const UserSchema = z.object({
+  email: z.string(),
+  name: z.string().optional(),
+  bio: z.string().optional()
+});
+
+// Valid inputs
+{ email: "test@example.com", name: "John", bio: "Developer" }
+{ email: "test@example.com", name: undefined, bio: undefined }
+{ email: "test@example.com" } // name and bio omitted
+
+// Invalid input
+{ email: "test@example.com", name: null } // ❌ null not allowed
+```
+
+### Nullable Behavior
+
+```typescript
+// generated/schemas/models/User.schema.ts
+export const UserSchema = z.object({
+  email: z.string(),
+  name: z.string().nullable(),
+  bio: z.string().nullable()
+});
+
+// Valid inputs
+{ email: "test@example.com", name: "John", bio: "Developer" }
+{ email: "test@example.com", name: null, bio: null }
+
+// Invalid input
+{ email: "test@example.com" } // ❌ name and bio must be present
+```
+
+## Type Compatibility
+
+All three behaviors produce types assignable to Prisma's generated input types, but they are **not** interchangeable at runtime: only `nullish` and `nullable` accept an explicit `null`.
+
+```typescript
+import { Prisma } from '@prisma/client';
+
+const prismaUser: Prisma.UserCreateInput = {
+  email: 'test@example.com',
+  name: null, // Prisma allows null for optional fields
+};
+
+// Valid under `nullish` (default) and `nullable`.
+// Rejected under `optional`, which does not accept an explicit null.
+UserSchema.parse(prismaUser);
+```
+
+## Use Cases
+
+### API Validation
+
+**Nullish** (default) is recommended for most API scenarios where clients can:
+
+- Omit fields entirely
+- Explicitly send null values
+- Send actual values
+
+### Strict Input Validation
+
+**Optional** is useful when you want to:
+
+- Allow fields to be omitted
+- Reject explicit null values
+- Maintain clean undefined-only semantics
+
+### Always-Present Fields
+
+**Nullable** is suitable when:
+
+- Fields must always be included in requests
+- Null is a meaningful value
+- You want to distinguish between "not set" and "explicitly null"
+
+## Object Schemas: Optional vs Nullable (Behavior Note)
+
+For input object schemas under `objects/` (e.g., `UserCreateInput.schema.ts`, `PostUpdateInput.schema.ts`), the generator applies a policy that aligns Prisma optionality with practical API usage:
+
+- Optional non‑relation fields (scalars/enums/unions) are emitted as `.optional().nullable()` to accept both omission and explicit `null`.
+- Optional relation‑shaped fields remain `.optional()` only and reject `null` (use omission to skip).
+
+Examples:
+
+```ts
+// Optional non-relation scalar
+name: z.string().optional().nullable()
+
+// Optional non-relation union (e.g., update operations)
+title: z.union([z.string(), TitleFieldUpdateOperationsInputObjectSchema]).optional().nullable()
+
+// Optional relation-shaped fields
+author: z.lazy(() => UserCreateNestedOneWithoutPostsInputObjectSchema).optional()         // ✅ undefined ok
+// author: null  // ❌ invalid, use omission instead
+```
+
+Additionally, in filter/where inputs, optional non-relation unions (e.g., `AND`, `OR`, `NOT`, or scalar filter unions) are treated as optional + nullable to allow `null` as a shorthand for “not applied”.
+
+Rationale:
+- Prisma optional fields often map to nullable columns; allowing `null` and omission improves ergonomics for JSON clients while keeping relation operations explicit and unambiguous.
+
+This policy applies to object input schemas irrespective of `optionalFieldBehavior`, which affects **pure model schemas only** (the `models/` output produced with `pureModels: true`).
+
+Variant schemas under `variants/` also ignore `optionalFieldBehavior` and use their own fixed policy for optional fields:
+
+- `input` variant → `.optional().nullable()`
+- `pure` and `result` variants → `.nullable()`
+
+## Migration
+
+When changing `optionalFieldBehavior`, regenerate your schemas:
+
+```bash
+npx prisma generate
+```
+
+The three behaviors differ in what they accept at runtime — `optional` rejects explicit `null`, `nullable` rejects omission — so switching between them can invalidate payloads that used to parse. Pick the one that matches your API contract.

package/website/docs/config/precedence.md

@@ -0,0 +1,68 @@
+---
+id: precedence
+title: Configuration Precedence
+---
+
+Final config is assembled in stages:
+
+1. Generator block options (Prisma `schema.prisma`) – highest priority.
+2. JSON config file – either the explicit `config` path or an auto-discovered file (see [Auto-Discovery](#auto-discovery)).
+3. Internal defaults (`processConfiguration`).
+
+## Config File Path Resolution
+
+Config file paths are resolved **relative to the Prisma schema file directory**, not the project root:
+
+```prisma title="prisma/schema.prisma"
+generator zod {
+  provider = "prisma-zod-generator"
+  config   = "./my-config.json"  // → prisma/my-config.json
+}
+```
+
+```prisma title="apps/api/schema.prisma"
+generator zod {
+  provider = "prisma-zod-generator"
+  config   = "../../shared/zod.config.json"  // → shared/zod.config.json
+}
+```
+
+This allows flexible config placement in monorepos and projects with custom schema locations.
+
+## Auto-Discovery
+
+When the generator block omits `config`, the generator looks for a config file **in the directory containing your `schema.prisma`** — the same base directory used for explicit `config` paths. For the usual `prisma/schema.prisma` layout that means every candidate below lives inside `prisma/`.
+
+Candidates are tried in this order:
+
+1. `zod-generator.config.json`
+2. `.zod-generator.json`
+3. `prisma/config.json` (i.e. `prisma/prisma/config.json` for the standard layout)
+4. `config.json`
+
+:::caution
+A config file at the **project root** is not auto-discovered, because discovery starts from the schema directory. Point at it explicitly instead:
+
+```prisma title="prisma/schema.prisma"
+generator zod {
+  provider = "prisma-zod-generator"
+  config   = "../zod-generator.config.json"  // → project-root config
+}
+```
+
+Only JSON is supported. The lookup also probes `zod-generator.config.js` and `.zod-generator.js`, but every candidate is read with `JSON.parse`, so an actual JavaScript module fails to load rather than being evaluated.
+:::
+
+## Unknown Keys Are Silently Ignored
+
+The generator does **not** validate your config against the JSON Schema. Generation runs `parseConfiguration` → `mergeConfigurationWithPrecedence` → `processConfiguration`; the only check applied to the file is that it parses as JSON and is an object. A misspelled key such as `pureModel` (instead of `pureModels`) or `strictmode` (instead of `strictMode`) is therefore accepted, dropped during merging, and never reported — which usually surfaces as "my setting did nothing".
+
+To catch typos, opt into schema validation: wire up `$schema` for editor squiggles and run `ConfigurationValidator` in CI. See [JSON Schema IntelliSense](./schema-json.md).
+
+## Output Path Resolution
+
+Output path resolution is deferred until after merging so a JSON `output` applies when the generator block omits `output`. Like config paths, output paths are also resolved relative to the schema file location.
+
+Conflict warnings are logged (file layout options) via `warnOnFileLayoutConflicts`—generator block wins.
+
+Legacy flags (e.g. `isGenerateSelect`, `isGenerateInclude`) are folded into the unified config; minimal mode forcibly disables select/include even if legacy flags true.

package/website/docs/config/schema-json.md

@@ -0,0 +1,68 @@
+---
+id: schema-json
+title: JSON Schema IntelliSense
+description: Wire up $schema in your config files for editor hints and automated validation.
+---
+
+The generator ships a [JSON Schema draft‑07](https://json-schema.org/) definition covering the config options. Point your config files at it once and editors give you IntelliSense, hover docs, and validation — and CI scripts can reuse the same definition.
+
+## Quick Start
+
+1. Make sure `prisma-zod-generator` is installed (the schema is published with every npm release under `lib/config/schema.json`).
+2. Open the config file you pass through the Prisma generator block (for example `prisma/config.json`, `zod-generator.config.json`, or whatever you set via `config = "./..."`).
+3. Add a `$schema` field that points to the installed package:
+
+```json title="prisma/config.json"
+{
+  "$schema": "../node_modules/prisma-zod-generator/lib/config/schema.json",
+  "mode": "full",
+  "pureModels": true
+}
+```
+
+Save the file and your editor immediately enables IntelliSense, hover docs, and red squiggles for invalid values.
+
+## Coverage
+
+The schema sets `additionalProperties: false`, so anything it does not model is reported as `Unknown property`. Everything the generator reads is now modelled, including the two cases that used to be gaps:
+
+- **Array-based custom variants.** `variants` accepts either the object form (`pure` / `input` / `result`) or the array of custom variants documented in [Variants System](./variants.md). Previously only the object form was modelled, so the array form was reported as `must be object`.
+- **`minimalOperations`** and the four dual-export keys (`exportTypedSchemas`, `exportZodSchemas`, `typedSchemaSuffix`, `zodSchemaSuffix`). These are read at generate time and were absent from the schema, so a config using them was reported as having unknown properties.
+
+:::note
+Editor reports and `ConfigurationValidator` never come from generation itself — the generator does not validate your config against this schema, so an unmodelled key still generates correctly. The flip side is that the generator will not warn you about a genuine typo either; see [Configuration Precedence → Unknown Keys Are Silently Ignored](./precedence.md#unknown-keys-are-silently-ignored).
+:::
+
+There is also one key the schema models but the generator ignores: `strictMode.enums` is accepted and offered by IntelliSense, yet nothing reads it (enum schemas are inherently strict). See [Strict Mode Configuration](./strict-mode.md#global-configuration).
+
+## Picking the Right Path
+
+- **Relative to config file** – Recommended because it survives CI and other machines. Use `../node_modules/...` if your config file sits inside the `prisma/` directory, or `./node_modules/...` if it lives at the project root.
+- **Absolute path** – Works for quick tests but breaks across machines. Prefer relative paths once you confirm things locally.
+- **Hosted copy** – If you host the schema at a stable URL (for example on your docs site or an internal CDN), set `$schema` to the HTTPS URL. Any consumer that understands JSON Schema will pull it remotely.
+
+## Programmatic Validation
+
+Need to fail CI when someone pushes an invalid config? Reuse the same schema through the compiled validator:
+
+```ts title="scripts/validate-config.ts"
+import { readFileSync } from 'node:fs';
+import { ConfigurationValidator } from 'prisma-zod-generator/lib/config/validator.js';
+
+const configPath = process.argv[2] ?? './prisma/config.json';
+const validator = new ConfigurationValidator();
+const config = JSON.parse(readFileSync(configPath, 'utf8'));
+const result = validator.validate(config);
+
+if (!result.valid) {
+  console.error('❌ Invalid Prisma Zod Generator config:');
+  console.error(result.errors);
+  process.exit(1);
+}
+
+console.log('✅ Config looks good');
+```
+
+Pair this with the `$schema` hint so editors catch problems before CI does. Every key the generator reads is modelled (see [Coverage](#coverage)), so this check is safe to make blocking.
+
+Once the `$schema` field is in place, every upgrade automatically refreshes the schema definition because the path always points to the version installed in `node_modules`.