@devmedic/config

Configuration schema, discovery, loading, and validation for DevMedic projects. Every shape is a Zod schema, so the types you get in an editor and the validation that runs at load time can never drift apart — see docs/configuration.md for the full, generated field reference and schema/devmedic.schema.json for the JSON Schema form (point a config file's "$schema" at it for editor validation).

Supported config files

Looked for in this order, in the project root; the first one found wins:

1. devmedic.config.ts — evaluated at runtime via jiti, no separate build step required
2. devmedic.config.json
3. devmedic.config.yaml / devmedic.config.yml
4. the "devmedic" key in package.json, if none of the above exist

If nothing is found, DevMedic runs with defaults — that's a valid, supported state, not an error.

// devmedic.config.ts
import { defineConfig } from '@devmedic/config';

export default defineConfig({
  ignore: ['**/generated/**'],
  ignoreRules: ['perf/no-sync-io-in-loop'],
  rules: {
    'security/no-eval': 'critical',
  },
  plugins: [
    '@devmedic/rule-pack-security',
    { name: './local-plugin.js', options: { strict: true } },
  ],
});

// devmedic.config.json
{
  "$schema": "./node_modules/@devmedic/config/schema/devmedic.schema.json",
  "ignore": ["**/generated/**"],
  "rules": { "security/no-eval": "critical" }
}

What it validates

• Ignored folders (ignore) — glob patterns, always unioned with a built-in baseline (node_modules, dist, .turbo, coverage, .git) that can't be accidentally dropped.
• Ignored rules (ignoreRules) — shorthand for setting a rule's severity to "off"; an explicit entry in rules for the same ID always wins.
• Custom severity (rules) — per-rule overrides keyed by "<category>/<rule-name>", validated against the Phase 0 naming convention.
• Custom plugins (plugins) — a bare package name/path, or { name, options } for namespaced plugin configuration.
• Future cloud settings (cloud) — reserved fields for the Phase 3 fleet dashboard; present now so config files don't need to change shape later, inert until then.

Every field is validated on load with resolveConfig — malformed config never throws past a call site; it comes back as a typed { ok: false, error } result (ConfigValidationError or ConfigLoadError), so callers (CLI, LSP, CI action) decide how to surface it. resolveConfigOrThrow is available for callers that prefer to throw.

Regenerating the docs

pnpm --filter @devmedic/config run docs

Regenerates both schema/devmedic.schema.json and docs/configuration.md from the Zod schema — never hand-edit either file.

Not yet implemented

The Phase 0 blueprint also scopes this package to hierarchical per-path overrides, an extends chain, and ESLint/Prettier/Checkstyle config importers. None of that is built yet — this pass covers discovery, the four file formats, validation, defaults, and generated docs only.

Depends on

• @devmedic/core