| name | no-inline-imports |
| description | Keep imports at the top of the module and avoid inline imports in function bodies, type annotations, or interface fields. Apply when writing, reviewing, or refactoring JavaScript or TypeScript, and whenever a dynamic `import()` or inline `import(...)` type appears in a diff. |
| paths | ["**/*.ts","**/*.tsx","**/*.js","**/*.jsx"] |
No inline imports
Always place imports at the top of the module.
Avoid inline imports in function bodies, type annotations, or interface fields unless there is a strict circular-dependency reason and it is documented.
What counts as an inline import
- A
require(...) or await import(...) inside a function body, branch, or callback.
- An inline
import("./module").SomeType used in a type annotation, interface field, or generic argument, instead of a top-level import type.
What to do instead
- Hoist the import to the top of the file with the rest of the imports.
- For types, use a top-level
import type { SomeType } from "./module".
- If the import genuinely must be deferred to break a circular dependency, keep it inline but leave a short comment naming the cycle it breaks, so the exception is visible to the next reader.
When reviewing
Flag inline imports that have no documented circular-dependency justification, and suggest the top-of-file replacement rather than just naming the problem.
