Disabling Inline Type Imports: ESLint And Tsconfig Guide

Nov 3, 2025 by Admin 57 views

Hey guys! Ever wondered how to keep your TypeScript code super clean and maintainable? One way to do that is by managing your imports effectively. Specifically, we're going to dive deep into disabling inline type imports using ESLint and tsconfig. Inline type imports, like the one you see below, can sometimes make your code a bit harder to read and manage:

initializeForOrder: (params: import('./drivePhotosTypes').OrderActionParams) => Promise<void>;
getOrderState: (orderId: string) => import('./drivePhotosTypes').OrderPhotosState | null;

Instead of having these inline imports scattered throughout your code, we’ll explore how to enforce a more structured approach. This means cleaner code, better readability, and fewer headaches down the road. So, let’s get started!

Why Disallow Inline Type Imports?

Before we jump into the how-to, let's quickly chat about why you might want to disallow inline type imports. It's not just about personal preference; there are some solid reasons for this.

First off, readability is key. When you have type definitions imported inline, it can clutter your code and make it harder to see the actual logic. Imagine trying to read a paragraph where every third word is a footnote – annoying, right? Inline imports can feel the same way.

Secondly, consistency is crucial in any project, especially when working in a team. By enforcing a rule against inline type imports, you ensure that everyone on the team imports types the same way. This uniformity makes the codebase more predictable and easier to navigate.

Thirdly, maintainability is improved by centralizing your imports. When types are imported at the top of the file, it's much easier to see all the dependencies at a glance. This becomes super handy when you need to refactor or update your code. You know exactly where your types are coming from without hunting through the file.

Finally, there's the potential for circular dependencies. While TypeScript is pretty good at handling these, explicitly importing types can sometimes help you avoid sneaky circular dependencies that might cause issues down the line. So, for cleaner, more consistent, and maintainable code, disallowing inline type imports is a smart move. Now, let's look at how to actually do it!

Using ESLint to Disallow Inline Type Imports

Okay, so you're convinced that disallowing inline type imports is a good idea. Awesome! Now, let's talk about how to actually enforce this rule using ESLint. If you're not already familiar, ESLint is a fantastic tool for linting your JavaScript and TypeScript code, helping you catch errors and enforce coding standards.

Setting Up ESLint

First things first, if you don't have ESLint set up in your project, you'll need to get that sorted. Here’s a quick rundown:

Install ESLint and TypeScript parser: You'll need the core ESLint library along with the TypeScript parser, which allows ESLint to understand your TypeScript code. Open up your terminal and run:

npm install eslint @typescript-eslint/parser --save-dev ```

Install the recommended TypeScript ESLint plugins: These plugins provide a bunch of useful rules specifically for TypeScript. We’ll be using one of them to disallow inline type imports. Install them with:

npm install @typescript-eslint/eslint-plugin --save-dev ```

Create an ESLint configuration file: If you don’t already have one, create an .eslintrc.js or .eslintrc.json file in the root of your project. This file tells ESLint how to lint your code.

Configuring ESLint to Disallow Inline Type Imports

Now comes the fun part: configuring ESLint to disallow inline type imports. We’ll use the @typescript-eslint/no-import-type-side-effects rule from the @typescript-eslint/eslint-plugin. This rule is specifically designed to prevent inline type imports.

Modify your ESLint configuration file: Open your .eslintrc.js (or .eslintrc.json) and add the following:
```
// .eslintrc.js
module.exports = {
  parser: '@typescript-eslint/parser',
  plugins: [
    '@typescript-eslint',
  ],
  extends: [
    'eslint:recommended',
    'plugin:@typescript-eslint/recommended',
  ],
  rules: {
    '@typescript-eslint/no-import-type-side-effects': 'error',
  },
};
```
Let's break down what’s happening here:
- parser: '@typescript-eslint/parser': This tells ESLint to use the TypeScript parser.
- plugins: ['@typescript-eslint']: This loads the TypeScript ESLint plugin.
- extends: This section extends existing ESLint configurations. We’re using eslint:recommended for general JavaScript rules and plugin:@typescript-eslint/recommended for TypeScript-specific recommended rules.
- rules: This is where we add our custom rules. The '@typescript-eslint/no-import-type-side-effects': 'error' line is the magic. It sets the no-import-type-side-effects rule to error, meaning ESLint will flag any inline type imports as errors.
Run ESLint: Now, run ESLint in your project. If you have it set up in your package.json, you might have a script like this:
```
// package.json
{
  "scripts": {
    "lint": "eslint . --ext .ts,.tsx"
  }
}
```
Run npm run lint (or your equivalent script), and ESLint will scan your code. Any inline type imports will now be flagged as errors, helping you clean up your codebase.

Example

If you have code like this:

// someFile.ts
import { SomeType } from './someOtherFile';

function doSomething(param: import('./someOtherFile').AnotherType) {
  // ...
}

ESLint will flag the param: import('./someOtherFile').AnotherType part as an error, encouraging you to import AnotherType at the top of the file instead.

Using tsconfig to Manage Type Imports

While ESLint is fantastic for enforcing coding style and catching errors, tsconfig.json is your go-to for controlling how TypeScript compiles your code. Unfortunately, tsconfig.json doesn't have a direct setting to disallow inline type imports like ESLint's @typescript-eslint/no-import-type-side-effects rule. However, you can use tsconfig.json to manage your module resolution and potentially reduce the need for inline imports.

Understanding Module Resolution

TypeScript uses module resolution to figure out where to find your modules and types. The moduleResolution setting in tsconfig.json plays a big role in this. Common options include node and classic. The node option is generally recommended as it mimics Node.js module resolution.

Here’s a basic tsconfig.json setup:

{
  "compilerOptions": {
    "moduleResolution": "node",
    "module": "commonjs",
    "target": "es5",
    "esModuleInterop": true,
    "strict": true,
    "baseUrl": ".",
    "paths": {
      "*": ["src/*"]
    }
  },
  "include": ["src/**/*"]
}

Let’s break down some key parts:

moduleResolution: Specifies the module resolution strategy. node is the modern and recommended approach.
module: Defines the module system. commonjs is commonly used for Node.js, while esnext is used for modern JavaScript modules.
baseUrl and paths: These are super useful for managing import paths. baseUrl sets the base directory for resolving non-relative module names, and paths lets you create aliases for module locations.

Using `paths` to Simplify Imports

The paths option is where you can really shine when it comes to managing imports. It allows you to create aliases for your modules, making your import statements cleaner and less prone to inline types.

For example, imagine you have a project structure like this:

src/
  components/
    MyComponent.tsx
  types/
    index.ts // Contains all your shared types

Without paths, you might end up with imports like this in MyComponent.tsx:

import { SomeType } from '../../types';

That ../../ can get messy and hard to read, especially in larger projects. With paths, you can clean this up.

Set up paths in tsconfig.json: Add a paths option to your tsconfig.json:
```
{
  "compilerOptions": {
    // ... other options
    "baseUrl": ".",
    "paths": {
      "@types/*": ["src/types/*"]
    }
  },
  // ...
}
```
Here, we’re telling TypeScript that any import starting with @types/ should be resolved under the src/types/ directory.
Update your imports: Now, you can update your imports in MyComponent.tsx:
```
import { SomeType } from '@types';
```
This is much cleaner and easier to read! Plus, it reduces the likelihood of needing inline type imports.

Why This Helps

While tsconfig.json can't directly disallow inline type imports, using paths and managing your module resolution effectively can significantly reduce the need for them. By creating cleaner, more direct import paths, you make it easier to import types at the top of your files, adhering to the best practice of avoiding inline type imports.

Best Practices for Managing Type Imports

Alright, we've covered how to use ESLint and tsconfig.json to help disallow inline type imports and manage your module resolution. Now, let's wrap up with some best practices to ensure your codebase stays clean and maintainable.

1. Import Types at the Top of the File

This one seems obvious, but it's worth reiterating: always aim to import your types at the top of your file. This makes it super clear what dependencies your module has and avoids the clutter of inline type imports. It’s like putting all your ingredients on the counter before you start cooking – you know exactly what you’re working with.

2. Use Type Aliases and Interfaces

TypeScript's type aliases and interfaces are your friends. Use them to create reusable type definitions. This not only makes your code more readable but also reduces duplication. For example, instead of repeating a complex type definition inline, define it once and import it wherever you need it.

// types.ts
export interface User {
  id: number;
  name: string;
  email: string;
}

// component.ts
import { User } from './types';

function displayUser(user: User) {
  // ...
}

3. Centralize Your Type Definitions

Consider creating a dedicated types directory (or similar) in your project to store your shared type definitions. This makes it easy for other modules to import and reuse these types. It’s like having a well-organized pantry – everything has its place, and it’s easy to find.

4. Leverage `paths` in `tsconfig.json`

As we discussed earlier, the paths option in tsconfig.json is a game-changer for managing import paths. Use it to create aliases for your modules, making your import statements cleaner and less verbose. This not only looks nicer but also makes your code easier to refactor.

5. Enforce Consistency with ESLint

ESLint is your trusty sidekick for enforcing coding standards. Use it to disallow inline type imports and catch other potential issues. Consistent code is happy code, and happy code is easier to maintain.

6. Be Mindful of Circular Dependencies

Circular dependencies can be a tricky beast. While TypeScript is pretty good at handling them, it’s still best to avoid them if possible. Explicitly importing types can sometimes help you spot and prevent circular dependencies. Keep an eye on your import structure and refactor if necessary.

7. Review and Refactor Regularly

Codebases evolve, and what worked yesterday might not be the best approach tomorrow. Regularly review your import patterns and type definitions. Refactor when necessary to keep your code clean, maintainable, and free of inline type imports.

Conclusion

So there you have it, folks! We’ve covered why disallowing inline type imports is a good idea, how to enforce this rule with ESLint, and how to manage module resolution with tsconfig.json. By following these practices, you'll be well on your way to writing cleaner, more maintainable TypeScript code. Remember, consistency and clarity are key to a happy codebase. Happy coding!