Best Practices

Practical ESLint guidance for Nova that uses a single flat config and small, ordered layers. Favor explicit, inspectable rules and predictable results.

Dos and Don'ts

DO: Use one flat config and start from Nova presets

• What: Use a single eslint.config.ts or eslint.config.js. 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.

DO: Order layers intentionally

• 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.

DO: Group rules into scoped entries

• 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.

DON'T: Mix flat config with legacy .eslintrc*

• What: Do not keep old config files alongside eslint.config.ts or eslint.config.js.
• Why: Split sources of truth cause confusion. Flat config expects rules and ignores to live in one place.

DON'T: Reorder config layers casually

• What: Avoid moving entries unless you intend to change who wins on conflicts.
• Why: Later entries override earlier ones. Order changes behavior.

DON'T: Lint build output or vendor folders

• 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