Entry points

Entry points are the foundation of graph-based checks. They tell rev-dep which files should be treated as the roots of reachable code.

Two kinds of entry points

• prodEntryPoints: application code that ships or runs in production
• devEntryPoints: tests, scripts, Storybook, build files, and other development-only entry points

Why they matter

These checks depend heavily on entry points:

• orphanFilesDetection
• unusedExportsDetection
• devDepsUsageOnProdDetection

If entry points are incomplete, reachable files may look orphaned and real tooling packages may look unused.

Good defaults

{
  "prodEntryPoints": ["src/index.ts*", "src/pages/**/*.ts*"],
  "devEntryPoints": ["scripts/**", "**/*.test.ts", ".storybook/**/*.ts"]
}

When in doubt, start narrow, review results, then add missing roots explicitly.

Rule-level defaults vs detector overrides

Most reachability-based detectors use rule-level prodEntryPoints and devEntryPoints as their foundation.

Some detectors also expose their own narrower knobs:

• orphanFilesDetection - validEntryPoints
• unusedExportsDetection - validEntryPoints
• devDepsUsageOnProdDetection - prodEntryPoints

Use those when one detector needs a smaller or more specific set of roots than the whole rule.

What belongs in dev entry points

Good candidates:

• tests
• Storybook files
• scripts
• local tooling entry scripts
• code generation entry files

In practice all not imported files that are in use for something should be added dev entry points.

Dealing with very long list of entry points

Some real life huge projects might have tens of entry points in different folders.

Good practice to keep the config lean is to group them by folders and use glob patterns to include all files in the folder.

If folders does not work, you can use file extension pattern like **/*.generated.ts or **/*.test.ts

With good convention in place, it's easier to add new entry points without needing to update the config every time.