Nested lint and format configs: share your use cases

[liangmiQwQ]

Vite+ currently reads lint and format settings from the root vite.config.ts, with lint.overrides and fmt.overrides for file- or package-specific settings. Nested lint and format configs are not currently supported.

We're holding off on adding support for now. Some of the factors we're considering are implicit config discovery, configuration semantics, the context AI agents need to understand which settings apply, and the potential performance cost of finding and loading multiple configs. At the same time, we recognize that keeping package-specific context close to the code may have benefits.

The use cases we've heard so far haven't given us a strong enough reason to commit to those semantics. Waiting leaves room to add support later, and we'd like to hear why your project needs nested configs, especially where root-level overrides fall short.

Do you need nested lint or format configs? Or do you have other approves to improve the current solution? Tell us.

It would help to hear:

• What problem would nested configs solve in your project?
• Where do root-level overrides or explicitly importing configuration objects become insufficient or awkward?
• Can you share a concrete example, such as your repository structure and the settings you'd want to keep in individual packages?

If the current approach works well for you, we'd like to hear that too. You don't need to propose an implementation—we're mainly interested in understanding your workflow and the reasons behind your preference.

[ryansuhartanto]

Two setups, one where the current approach works and one where it has a sharp edge.

Context for where this is coming from: I maintain https://github.com/kekkon-nexus/config, a published preset package for oxlint, oxfmt, tsconfig and commitlint, so my interest is less as a monorepo owner and more as someone whose presets end up in other people's repos. I also arrived here from #2698, so I have a mild bias toward nested lookup staying off.

Where root-level composition works

The preset repo itself: Bun workspace, packages/*, one root vite.config.ts, no per-package config.

import fmt from "@kekkon-nexus/config/oxfmt";
import base from "@kekkon-nexus/config/oxlint";
import vp from "@kekkon-nexus/config/oxlint/vite-plus";

export default defineConfig({
  fmt: { ...fmt },
  lint: { extends: [base, vp], options: { typeAware: true, typeCheck: true } },
});

Granularity comes from the export map (./oxlint/vitest, ./oxlint/react, ./oxlint/node, and so on) rather than from file location, so a package needing a different rule set imports a different preset. That covers plugins too, not just rules: ./oxlint/vite-plus extends the vitest preset and adds vite-plus/oxlint-plugin.

The reason I prefer keeping it explicit is testability. I can import a preset, inspect the resolved object, and assert on it. With implicit discovery my presets get merged by precedence rules I don't control and can't reproduce in a test, and a consumer's bug report becomes "which file won" instead of "here's the object you produced".

Caveat: that tree is homogeneous TypeScript, so it has never stress-tested the polyglot case nested configs presumably exist for.

Where the current behaviour is not neutral

A different repo https://github.com/ryansuhartanto/koda-b8-phase3-project, a root with two git submodules. Each a standalone repo with its own vite.config.js and its own node_modules.

project/
vite.config.js
frontend/ (submodule, own config: react, tailwind, no-relative-import-paths)
backend/ (submodule, own config: pack entry, no-relative-import-paths)

vp lint at the root, and inside each submodule:

	files	rules	time
root	69	451	5.3s
backend	31	452	1.6s
frontend	36	452	2.2s

The root run covers the same files (31 + 36, plus two at the root) but applies one fewer rule, because both submodule configs register eslint-plugin-no-relative-import-paths and the root config does not. Confirmed by removing that plugin from the backend config: 452 becomes 451.

Right now that rule matches nothing, so the diagnostics from both paths are identical and the only signal is the rule count in the summary. With a submodule-specific rule that does fire, root CI passes while submodule CI fails, and nothing in the output explains the difference.

I don't think nested discovery is the answer here, though. These aren't nested configs semantically: each submodule is the root of its own repo, resolves @kekkon-nexus/config through its own node_modules, and can be checked out at any path or cloned alone. Walking up out of a submodule into whatever happens to enclose it would be wrong more often than right. I run the three separately for that reason.

So the gap I'd point at isn't missing nested support, it's that a root run silently applies fewer rules than the per-repo runs with no indication it found configs it isn't using.

[liangmiQwQ]

Thank you for explaining. I guess you actually need a thing more like sub-package config rather than nested config, right? Just like today's other config items like pack / build where you can set per-package config in detail and they won't be shadowed by a high-level config.

Just want to notice: In fact, Oxlint and Oxfmt's nested config won't merge the found vite.config.ts with the root-level vite.config.ts. Instead, it just treat the found config as the one to check files. It is quite similar to your Sub-models shouldn't be effected by a parent config idea.