Mastering Type-Only Imports in TypeScript

TypeScript's import type feature allows for cleaner, more performant code by ensuring that imports are entirely erased during compilation, leaving no runtime JavaScript footprint. This challenge focuses on understanding and correctly implementing type-only imports to separate type dependencies from runtime JavaScript dependencies.

Problem Description

Your task is to refactor a given TypeScript codebase to utilize import type for all imports that are solely used for type annotations or declarations. This means any import that doesn't contribute any actual JavaScript values at runtime should be converted.

Key Requirements:

Identify and convert type-only imports: Go through the provided code and find all import statements where the imported module is only used for its types (interfaces, types, enums, etc.) and not for any runtime values (functions, classes, variables).
Replace with import type: Convert these identified imports from standard import ... from '...' or import { ... } from '...' to import type { ... } from '...'.
Maintain runtime behavior: Ensure that after the refactoring, the JavaScript output of the code behaves exactly as it did before. This implies that no runtime values should be inadvertently removed or added.
Preserve type safety: The TypeScript compilation should still pass, meaning all type checks remain valid.

Expected Behavior:

All imports that are not used as runtime values (e.g., only used in interface definitions, type aliases, or function parameter/return types) should be converted to import type.
Imports that are used as runtime values (e.g., a utility function, a component class) should remain as standard imports.
The final compiled JavaScript should be identical to the JavaScript produced before the refactoring.
The TypeScript code should compile without errors.

Edge Cases:

Mixed imports: Be mindful of modules where some exports are types and others are values. You might need to split imports or use import type for only the type parts.
Namespace imports: If a namespace import is only used for types, it should be converted.
Default imports: If a default import is only used for its type information, it should also be converted using import type.

Examples

Example 1:

Input Code (src/utils.ts):

export interface User {
  id: number;
  name: string;
}

export function greet(user: User): string {
  return `Hello, ${user.name}!`;
}

export const defaultGreeting = "Hello";

Input Code (src/main.ts):

import { User, greet, defaultGreeting } from './utils'; // User is only used for type

const user: User = { id: 1, name: "Alice" };
console.log(greet(user));
console.log(defaultGreeting);

Refactored Code (src/main.ts):

import type { User } from './utils';
import { greet, defaultGreeting } from './utils'; // greet and defaultGreeting are used at runtime

const user: User = { id: 1, name: "Alice" };
console.log(greet(user));
console.log(defaultGreeting);

Explanation: The User interface is only used for type annotation of the user variable. Therefore, the import for User is converted to import type { User }. The greet function and defaultGreeting variable are used at runtime, so their import remains standard.

Example 2:

Input Code (src/config.ts):

export type AppConfig = {
  version: string;
  environment: 'development' | 'production';
};

export const MAX_RETRIES = 3;

Input Code (src/service.ts):

import { AppConfig, MAX_RETRIES } from './config'; // AppConfig is only used for type

function processData(config: AppConfig) {
  console.log(`Processing in ${config.environment} mode.`);
  // ... other logic using MAX_RETRIES implicitly or explicitly
}

processData({ version: '1.0.0', environment: 'development' });

Refactored Code (src/service.ts):

import type { AppConfig } from './config';
import { MAX_RETRIES } from './config'; // MAX_RETRIES is a value

function processData(config: AppConfig) {
  console.log(`Processing in ${config.environment} mode.`);
  // ... other logic using MAX_RETRIES implicitly or explicitly
}

processData({ version: '1.0.0', environment: 'development' });

Explanation: AppConfig is exclusively used for type declarations. MAX_RETRIES is a constant value that might be used in runtime logic (though not explicitly shown here, it's a common pattern). Thus, AppConfig is imported with import type, while MAX_RETRIES is imported normally.

Example 3: Mixed Exports and Default Import

Input Code (src/types.ts):

export interface Logger {
  log(message: string): void;
  error(message: string): void;
}

export const defaultLogLevel = 'info';

export default class ConsoleLogger implements Logger {
  log(message: string): void {
    console.log(message);
  }
  error(message: string): void {
    console.error(message);
  }
}

Input Code (src/app.ts):

import Logger, { defaultLogLevel } from './types'; // Logger is a class used at runtime

// Type for logger instance, not a runtime value itself
type MyLogger = Logger;

function setup(loggerInstance: MyLogger) {
  loggerInstance.log("App started");
}

const consoleLogger: MyLogger = new ConsoleLogger(); // ConsoleLogger is a runtime value
setup(consoleLogger);

Refactored Code (src/app.ts):

import type Logger from './types'; // Logger type is used for annotation
import { defaultLogLevel } from './types'; // defaultLogLevel is a value

// Type for logger instance, not a runtime value itself
type MyLogger = Logger;

function setup(loggerInstance: MyLogger) {
  loggerInstance.log("App started");
}

// The actual class ConsoleLogger needs to be imported to be instantiated
import ConsoleLogger from './types';

const consoleLogger: MyLogger = new ConsoleLogger(); // ConsoleLogger is a runtime value
setup(consoleLogger);

Explanation: The Logger interface is used in the MyLogger type alias, making it a type-only dependency in this context. The defaultLogLevel is a runtime value. The ConsoleLogger class is a runtime value that needs to be instantiated. The initial import needs to be split. The Logger type can be imported with import type. The defaultLogLevel can be imported normally. The ConsoleLogger class, being a runtime value, also needs a standard import if it's used to instantiate objects. The example is tricky because Logger in the original import refers to the default export which is the ConsoleLogger class, but the MyLogger type alias is using the name Logger to refer to the interface.

Corrected Refactored Code (src/app.ts) to address the default export ambiguity:

import type { Logger as LoggerInterface } from './types'; // Import interface as a type
import ConsoleLogger from './types'; // Import the default export (class) for runtime use
import { defaultLogLevel } from './types'; // Import value

// Use the imported interface as the type
type MyLogger = LoggerInterface;

function setup(loggerInstance: MyLogger) {
  loggerInstance.log("App started");
}

const consoleLogger: MyLogger = new ConsoleLogger(); // Instantiate the class
setup(consoleLogger);

Explanation for Corrected Refactored Code: This example highlights a common ambiguity: when a module exports both a default class and named types.

The Logger interface is only used as a type annotation (MyLogger). We import it specifically as LoggerInterface using import type { Logger as LoggerInterface }.
The defaultLogLevel is a runtime value, so it's imported normally.
The ConsoleLogger class (the default export) is used to instantiate consoleLogger at runtime. Therefore, it requires a standard import import ConsoleLogger from './types'.
The MyLogger type alias now correctly uses LoggerInterface.

Constraints

The provided codebase will be a set of interconnected TypeScript files.
The solution must be written in TypeScript.
The refactored code must pass TypeScript compilation with strict type checking enabled.
The compiled JavaScript output should be functionally identical to the original compiled JavaScript output (no runtime behavior changes).
The focus is on understanding the import type syntax and its implications.

Notes

Consider the difference between importing a type/interface and importing a class/function/variable.
import type will completely remove the import from the generated JavaScript.
If a module contains both types and values, you might need to have separate imports: one using import type for types and another standard import for values.
Pay close attention to default exports versus named exports.
The goal is to improve code clarity and potentially runtime performance by eliminating unnecessary JavaScript imports.