Skip to main content

Best Practices

Practical ESLint guidance for Nova that uses a single flat config and small, ordered layers. Favor explicit, inspectable rules and predictable results. These practices apply to any workspace in a monorepo.

Dos and Don'ts

  • What: Use a single eslint.config.ts. First import Nova presets, then add your project's layers and overrides in that same array.
  • Why: One file is the source of truth. Presets give a reliable base. Your local entries then adjust behavior in a controlled, visible order.
  • What: Arrange as ignores → style → language → environment/framework → platform → tool → your custom overrides.
  • Why: ESLint merges top to bottom and the last matching entry wins. Stable order makes outcomes predictable.
  • What: Create an array of objects. Each object is a named group with plugins, rules, settings, files, ignores, etc.
  • Why: You control where a ruleset applies. This replaces legacy overrides and avoids accidental coverage.
  • What: Do not keep old config files alongside eslint.config.ts.
  • Why: Split sources of truth cause confusion. Flat config expects rules and ignores to live in one place.
  • What: Avoid moving entries unless you intend to change who wins on conflicts.
  • Why: Later entries override earlier ones. Order changes behavior.
  • What: Exclude generated code (e.g. build, dist, node_modules) from linting.
  • Why: Prevents noise, speed issues, and irrelevant rule failures from user-ignored files.

Troubleshooting

Find issues by using the command below to print the effective config:

eslint --print-config ./path/to/file.ts