## The Error

> Relative import paths need explicit file extensions in EcmaScript imports when '--moduleResolution' is 'node16' or 'nodenext'.

```ts
// Relative import paths need explicit file extensions in
// EcmaScript imports when '--moduleResolution' is 'node16'
// or 'nodenext'.

import { example } from "./foo";
```

---

## The Solution That Doesn't Work

Adding a `.ts` extension to the import path doesn't work, and results in the following error:

> An import path can only end with a '.ts' extension when 'allowImportingTsExtensions' is enabled.

```ts
// An import path can only end with a '.ts' extension when
// 'allowImportingTsExtensions' is enabled.

import { example } from "./foo.ts";
```

## The Solution

Add the `.js` extension to the import path.

```ts
import { example } from "./foo.js";
```

---

## Why Do We Need to Use JS File Extensions?

This error happens because you've specified `moduleResolution: NodeNext`. This tells TypeScript that you want your imports and exports to conform strictly to the Node spec.

The Node spec requires that you use `.js` file extensions for all imports and exports. This was decided so that a relative import path like `./foo.js` would work both in [Node and the browser](https://twitter.com/giltayar/status/1711669549760757997).

This also simplifies Node's module resolution strategy - Node doesn't have to do any guesswork to figure out what file to import. Thanks to [Gil Tayer](https://twitter.com/giltayar/status/1711670026464354460) for clarifying this for me.

## What if I don't want to use JS file extensions?

- Make sure you're using an external compiler, like esbuild, to compile your TypeScript code.
- Change your `tsconfig.json` to use `moduleResolution: Bundler` instead of `moduleResolution: NodeNext`.


When using '--moduleResolution' with the option 'nodenext', it is necessary to add explicit file extensions to relative import paths in EcmaScript imports.

Relative import paths need explicit file extensions in EcmaScript imports

A common problem in TypeScript is that `process.env` doesn't give you autocomplete for the environment variables that actually exist in your system:

```ts twoslash
declare const process: {
  env: Record<string, string | undefined>;
};

// ---cut---

console.log(process.env.MY_ENV_VARIABLE); // No autocomplete
```

They also end up typed as `string | undefined`, which can be annoying if you're passing them into functions that expect a string:

```ts twoslash
// @errors: 2345
declare const process: {
  env: Record<string, string | undefined>;
};

// ---cut---

const myFunc = (envVar: string) => {
  console.log(envVar.toUpperCase());
};

myFunc(process.env.MY_ENV_VARIABLE);
```

Here are a few ways to strongly type `process.env`:

## Solution 1: Augment The Global Type

You can augment the global type `NodeJS.ProcessEnv` to include your environment variables:

```ts
// globals.d.ts
namespace NodeJS {
  interface ProcessEnv {
    MY_ENV_VARIABLE: string;
  }
}
```

This relies on declaration merging on the global interface `NodeJS.ProcessEnv`, adding an extra property `MY_ENV_VARIABLE`.

Now, in every file in your project, you'll get autocomplete for `MY_ENV_VARIABLE`, and it'll be typed as a string.

```ts twoslash
// @errors: 2345
declare const process: {
  env: {
    MY_ENV_VARIABLE: string;
  };
};

const myFunc = (envVar: string) => {
  console.log(envVar.toUpperCase());
};

// ---cut---

myFunc(process.env.MY_ENV_VARIABLE);
//                 ^?
```

However, this doesn't provide any guarantees that the environment variable actually exists in your system.

This means that it's useful when you have relatively few environment variables, or can't get buy-in to add an extra library for checking them.

## Solution 2: Validate It At Runtime With `t3-env`

If you want to validate that all your environment variables are present at runtime, you can use a library like [`t3-env`](https://github.com/t3-oss/t3-env).

This leverages zod to validate your environment variables at runtime. Here's an example:

```ts
import { createEnv } from "@t3-oss/env-core";
import { z } from "zod";

export const env = createEnv({
  server: {
    DATABASE_URL: z.string().url(),
    OPEN_AI_API_KEY: z.string().min(1),
  },
  clientPrefix: "PUBLIC_",
  client: {
    PUBLIC_CLERK_PUBLISHABLE_KEY: z.string().min(1),
  },
  runtimeEnv: process.env,
});
```

This will fail at runtime if any of the environment variables are missing or don't match the schema. It also means you can leverage Zod's powerful validation capabilities, such as `.url()` or `.min(1)` for strings.

It also provides a single source of truth for your environment variables - `env`. This means you can use `env` throughout your codebase, and you'll get autocomplete and type-checking for your environment variables.

Here's a [great guide](https://env.t3.gg/docs/core) you can use to get started.

## Which Solution Should You Use?

If your project is small and you don't want to add extra dependencies, augmenting the global type is a good solution.

But if you're remotely concerned about missing environment variables at runtime, `t3-env` is a great choice.


Learn how to strongly type process.env in TypeScript by either augmenting global type or validating it at runtime with t3-env.

How To Strongly Type process.env

`any` is an extremely powerful type in TypeScript. It lets you treat a value as if you were in JavaScript, not TypeScript. This means that it disables all of TypeScript's features - type checking, autocomplete, and safety.

```ts twoslash
const myFunction = (input: any) => {
  input.someMethod();
};

myFunction("abc"); // This will fail at runtime!
```

Using `any` is rightly considered harmful by most of the community. There are [ESLint rules](https://typescript-eslint.io/rules/no-explicit-any/) to prevent its use. This can turn developers off using `any` entirely.

However, there are a few advanced cases where `any` is always the right choice. Here are some of them:

## Type Argument Constraints

Let's imagine we wanted to implement the `ReturnType` utility in TypeScript. This utility takes a function type and returns the type of its return value.

We need to create a [generic type](https://www.totaltypescript.com/no-such-thing-as-a-generic#generic-types) which takes a function type as a type argument. If we restricted ourselves to not use `any`, we might use `unknown`:

```ts twoslash
// @moduleDetection: force
type ReturnType<T extends (...args: unknown[]) => unknown> =
  // Not important for our explanation:
  T extends (...args: unknown[]) => infer R ? R : never;
```

It's not important to understand _all_ of this code, only the constraint - `T extends (...args: unknown[]) => unknown`. What we're saying here is that only functions which accept an arguments array of `unknown[]` and return `unknown` are allowed.

It seems to work fine for functions which have no arguments:

```ts twoslash
// @moduleDetection: force
type ReturnType<T extends (...args: unknown[]) => unknown> =
  T extends (...args: unknown[]) => infer R ? R : never;

// ---cut---

const myFunction = () => {
  console.log("Hey!");
};

type Result = ReturnType<typeof myFunction>;
//   ^?
```

But it stops working as soon as we add an argument:

```ts twoslash
// @moduleDetection: force
// @errors: 2344
type ReturnType<T extends (...args: unknown[]) => unknown> =
  T extends (...args: unknown[]) => infer R ? R : never;

// ---cut---

const myFunction = (input: string) => {
  console.log("Hey!");
};

type Result = ReturnType<typeof myFunction>;
```

In fact, it only works if we change the parameter of our function to `input: unknown`:

```ts twoslash
// @moduleDetection: force
type ReturnType<T extends (...args: unknown[]) => unknown> =
  T extends (...args: unknown[]) => infer R ? R : never;

// ---cut---

const myFunction = (input: unknown) => {
  console.log("Hey!");
};

type Result = ReturnType<typeof myFunction>;
//   ^?
```

So accidentally, we've created a `ReturnType` function that only works on functions which accept `unknown` as an argument. This is not what we wanted. We wanted it to work on any function.

The solution is to use `any[]` as the type argument constraint:

```ts twoslash
// @moduleDetection: force
type ReturnType<T extends (...args: any[]) => any> =
  T extends (...args: any[]) => infer R ? R : never;

const myFunction = (input: string) => {
  console.log("Hey!");
};

type Result = ReturnType<typeof myFunction>;
//   ^?
```

Now it works as expected. We're declaring that we don't care what types the function accepts - it could be anything.

The reason this is safe is because we're deliberately declaring a wide type. We're saying "I don't care what the function accepts, as long as it's a function". This is a safe use of `any`.

## Returning Conditional Types From Generic Functions

In some places, TypeScript's narrowing abilites are not as good as we'd like them to be. Let's say we want to create a function which returns different types based on a condition:

```ts twoslash
const youSayGoodbyeISayHello = (
  input: "hello" | "goodbye"
) => {
  if (input === "goodbye") {
    return "hello";
  } else {
    return "goodbye";
  }
};

const result = youSayGoodbyeISayHello("hello");
//    ^?
```

This function isn't really doing what we want it to. We want it to return the type `"goodbye"` when we pass in `"hello"`. But currently, `result` is typed as `"hello" | "goodbye"`.

We can fix this by using a conditional type:

```ts twoslash
// @noErrors
const youSayGoodbyeISayHello = <
  TInput extends "hello" | "goodbye"
>(
  input: TInput
): TInput extends "hello" ? "goodbye" : "hello" => {
  if (input === "goodbye") {
    return "hello";
  } else {
    return "goodbye";
  }
};

const goodbye = youSayGoodbyeISayHello("hello");
//    ^?
const hello = youSayGoodbyeISayHello("goodbye");
//    ^?
```

We've added a conditional type to the return type of the function which mirrors our runtime logic. If `TInput`, inferred from the runtime argument `input`, is `"hello"`, we return `"goodbye"`. Otherwise, we return `"hello"`.

But there's a problem. I've deliberately disabled the errors in the snippet above. Let's see what happens when we enable them:

```ts twoslash
// @errors: 2322
const youSayGoodbyeISayHello = <
  TInput extends "hello" | "goodbye"
>(
  input: TInput
): TInput extends "hello" ? "goodbye" : "hello" => {
  if (input === "goodbye") {
    return "hello";
  } else {
    return "goodbye";
  }
};
```

Ouch. TypeScript doesn't seem to be matching up the conditional type with the runtime logic. `"hello"` or `"goodbye"` can't be returned from the function.

We can fix this by using `as`, and forcing it to be the correct conditional type:

```ts twoslash
// @errors: 2322
const youSayGoodbyeISayHello = <
  TInput extends "hello" | "goodbye"
>(
  input: TInput
): TInput extends "hello" ? "goodbye" : "hello" => {
  if (input === "goodbye") {
    return "hello" as TInput extends "hello"
      ? "goodbye"
      : "hello";
  } else {
    return "goodbye" as TInput extends "hello"
      ? "goodbye"
      : "hello";
  }
};
```

We can make this nicer by extracting that logic to a common generic type:

```ts twoslash
// @errors: 2322

type YouSayGoodbyeISayHello<
  TInput extends "hello" | "goodbye"
> = TInput extends "hello" ? "goodbye" : "hello";

const youSayGoodbyeISayHello = <
  TInput extends "hello" | "goodbye"
>(
  input: TInput
): YouSayGoodbyeISayHello<TInput> => {
  if (input === "goodbye") {
    return "hello" as YouSayGoodbyeISayHello<TInput>;
  } else {
    return "goodbye" as YouSayGoodbyeISayHello<TInput>;
  }
};
```

But in these situations, it often makes more sense to use `as any`:

```ts twoslash
// @errors: 2322
const youSayGoodbyeISayHello = <
  TInput extends "hello" | "goodbye"
>(
  input: TInput
): TInput extends "hello" ? "goodbye" : "hello" => {
  if (input === "goodbye") {
    return "hello" as any;
  } else {
    return "goodbye" as any;
  }
};
```

Yes, this does make our function less type-safe. We could accidentally return `"bonsoir"` from the function instead.

But in these situations, it's often better to use `as any` and add a unit test for this function's behavior. Because of TypeScript's limitations in checking this stuff, this is often as close as you'll get to type safety.

There are several other use cases like this, where inside generic functions you need to use `any` to get around TypeScript's limitations. To me, this is fine.

## Conclusion

A question remains: should you ban `any` from your codebase? I think, on balance, the answer should be yes. You should turn on the ESLint rule which prevents its use, and you should avoid it wherever possible.

However, there _are_ cases where `any` is needed. They're worth using `eslint-disable` to get around them. So, bookmark this article, and attach it to your PR's when you feel the need to use it.

Have you spotted any other legitimate use cases for `any`? Let me know!

<FeedbackFormButton />


Discover when it's appropriate to use TypeScript's `any` type despite its risks. Learn about legitimate cases where `any` is necessary.

`any` Considered Harmful, Except For These Cases

I tend to get involved in a lot of discussions about TypeScript online. And one of the most common misconceptions I see from folks just learning about TypeScript is that TypeScript's types exist at runtime.

This idea feels obvious when you come to TypeScript from other strongly-typed languages. In those languages, types are a fundamental part of the language. They're used to influence the runtime behavior of the program.

But TypeScript is different - TypeScript's types don't exist at runtime. They're only used to help you catch errors at compile time. This is because TypeScript is designed to compile down to JavaScript, which doesn't have a type system.

Let's look at a few examples:

## Types

Types and interfaces let you describe the shape of a type. You will have thousands of lines of type declarations in your program. But they don't exist at runtime:

<TranspilePreview>

```ts
type Person = {
  name: string;
  age: number;
};

const person: Person = {
  name: "Alice",
  age: 30,
};

interface Animal {
  name: string;
  age: number;
}

const animal: Animal = {
  name: "Fluffy",
  age: 5,
};
```

</TranspilePreview>

Notice how the types `Person` and `Animal` are gone in the transpiled JavaScript, and all you're left with is the object literals.

## Type Assertions

You can use type assertions to tell TypeScript that you know more about a value than it does. But these assertions don't exist at runtime:

<TranspilePreview>

```ts
const str = "Hello, world!";

const num: number = str as unknown as number;
```

</TranspilePreview>

Just because `num` has been asserted to be a number doesn't mean it is one at runtime. TypeScript will trust you that `str` is a number, but if it's not, you'll get a runtime error.

This is a reason why type assertions are discouraged in TypeScript. They can lead to runtime errors if you're not careful.

## Function Parameters

You can use types to describe the shape of a function's parameters. But these types don't exist at runtime. They don't guarantee that your function will be called with the right arguments:

<TranspilePreview>

```ts
const add = (a: number, b: number) => a + b;

add(1, 2);

add("1" as any, "2" as any);
```

</TranspilePreview>

Notice that there is no extra code in the transpiled JavaScript to check that `add` is being called with the right arguments.

## Enums, Namespaces and Parameter Properties

There are some exceptions to this rule. Enums, namespaces, and parameter properties do have a runtime representation:

<TranspilePreview>

```ts
// Enums
enum Direction {
  Up,
  Down,
  Left,
  Right,
}

// Namespaces
namespace Geometry {
  export const PI = 3.14159;
}

// Parameter Properties
class Person {
  constructor(public name: string) {}
}
```

</TranspilePreview>

Most features in TypeScript disappear at runtime, but these three are the exception. They have a runtime representation that can be used in your program.

These features are all pretty old. They were added in an era when JavaScript was seen as relatively stagnant - and TypeScript was attractive because it added much-needed features like enums, classes and namespaces.

But now, JavaScript is in a much healthier place. It has classes built in. It has modules, which are an improved version of namespaces. Someday, according to [this proposal](https://github.com/rbuckton/proposal-enum), it might have enums.

So now, TypeScript takes a different approach - it sees its job as adding types to JavaScript, not adding new features to the language. If enums, namespaces or parameter properties were proposed now, they wouldn't be added to TypeScript.

This means that thinking of TypeScript as just adding types to JavaScript is a useful rule of thumb - with the exception of enums, namespaces and parameter properties.


Learn why TypeScript's types don't exist at runtime. Discover how TypeScript compiles down to JavaScript and how it differs from other strongly-typed languages.

No, TypeScript Types Don't Exist At Runtime

A couple of years ago, Sentry were having big problems with their React app. They'd pretty recently [migrated it to TypeScript](https://blog.sentry.io/slow-and-steady-converting-sentrys-entire-frontend-to-typescript) from JavaScript. And the app was part of a large monorepo.

But the IDE performance was slow. You'd often need to wait a couple of seconds after making a change for the TypeScript language server to update. And running `tsc` would take a long time.

Now, this isn't unusual for a large TypeScript codebase. But the Sentry team had a hunch that something was wrong. The problem felt out of proportion to the size of the codebase.

It turned out that the issue, outlined by [Jonas](https://twitter.com/JonasBadalic/status/1765006152150974919), was down to a single pattern.

## How To Tank Your React App's TS Performance

In tons of places in Sentry's codebase, they were extending HTML types in React. For instance, defining `ButtonProps` would look like this:

```tsx twoslash
import React from "react";

type ButtonProps =
  React.HTMLAttributes<HTMLButtonElement> & {
    extraProp: string;
  };

const Button = ({ extraProp, ...props }: ButtonProps) => {
  console.log(extraProp);
  return <button {...props} />;
};
```

This means that you could pass in all the props that a `<button>` element could take, plus an `extraProp`:

```tsx twoslash
import React from "react";

type ButtonProps =
  React.HTMLAttributes<HTMLButtonElement> & {
    extraProp: string;
  };

const Button = ({ extraProp, ...props }: ButtonProps) => {
  console.log(extraProp);
  return <button {...props} />;
};

// ---cut---

<Button
  extraProp="whatever"
  onClick={(e) => {
    //      ^?
  }}
/>;
```

But it turns out that this pattern is devilishly slow. So Jonas, following the advice of the [TypeScript Performance Wiki](https://github.com/microsoft/TypeScript/wiki/Performance), changed each of these to use an `interface` instead:

```tsx twoslash
import React from "react";

interface ButtonProps
  extends React.HTMLAttributes<HTMLButtonElement> {
  extraProp: string;
}
```

Suddenly, things got a lot snappier. The TypeScript language server was faster, and `tsc` ran quicker. Just from a little syntax change. Why?

## Why Did This Happen?

You may have heard that `interface` is slightly faster than `type`. This is not quite true. In fact, `interface extends` is slightly faster than `&`.

In an earlier version of this article, I'd posted an explanation based on some fuzzy thinking which, thanks to my old colleague [
Mateusz Burzyński](https://twitter.com/AndaristRake), I now understand was wrong.

The problem is more complex than I realised - check out [this thread](https://twitter.com/AndaristRake/status/1770743549325115459) for his critiques and our investigations.

Hopefully, I can update this article again with a definitive description of why this happens - but nothing is simple when it comes to TypeScript performance.

Suffice to say - `interface extends` is generally faster than `&`, and so it proved in this case too.

Improve React TypeScript performance by replacing type & with interface extends. Boost IDE and tsc speed significantly.

This Pattern Will Wreck Your React App's TS Performance

One of the most common pieces of advice for writing maintainable code is to "Keep code DRY", or more explicitly, "Don't Repeat Yourself".

One way to do this in JavaScript is to take repeating code and capture it in functions or variables. These variables and functions can be reused, composed and combined in different ways to create new functionality.

In TypeScript, we can apply this same principle to types.

## What Is A Derived Type?

A derived type is a type which relies on, or inherits from, a structure of another type. We can create derived types using some of the tools we've used so far.

We could use `interface extends` to make one interface inherit from another:

```typescript
interface Album {
  title: string;
  artist: string;
  releaseYear: number;
}

interface AlbumDetails extends Album {
  genre: string;
}
```

`AlbumDetails` inherits all of the properties of `Album`. This means that any changes to `Album` will trickle down to `AlbumDetails`. `AlbumDetails` is derived from `Album`.

Another example is a union type.

```typescript
type Triangle = {
  type: "triangle";
  sideLength: number;
};

type Rectangle = {
  type: "rectangle";
  width: number;
  height: number;
};

type Shape = Triangle | Rectangle;
```

A derived type represents a relationship. That relationship is one-way. `Shape` can't go back and modify `Triangle` or `Rectangle`. But any changes to `Triangle` and `Rectangle` will ripple through to `Shape`.

## Deriving vs Decoupling

When you derive a type from a source, you're coupling the derived type to that source. If you derive a type from another derived type, this can create long chains of coupling throughout your app that can be hard to manage.

### When Decoupling Makes Sense

Let's imagine we have a `User` type in a `db.ts` file:

```typescript
export type User = {
  id: string;
  name: string;
  imageUrl: string;
  email: string;
};
```

We'll say for this example that we're using a component-based framework like React, Vue or Svelte. We have a `AvatarImage` component that renders an image of the user. We could pass in the `User` type directly:

```tsx
import { User } from "./db";

export const AvatarImage = (props: { user: User }) => {
  return <img src={props.user.imageUrl} alt={props.user.name} />;
};
```

But as it turns out, we're only using the `imageUrl` and `name` properties from the `User` type. It's a good idea to make your functions and components only require the data they need to run. This helps prevent you from passing around unnecessary data.

Let's try deriving. We'll create a new type called `AvatarImageProps` that only includes the properties we need:

```tsx
import { User } from "./db";

type AvatarImageProps = Pick<User, "imageUrl" | "name">;
```

But let's think for a moment. We've now coupled the `AvatarImageProps` type to the `User` type. `AvatarImageProps` now not only depends on the shape of `User`, but its _existence_ in the `db.ts` file. This means if we ever move the location of the `User` type, or split it into separate interfaces, we'll need to think about `AvatarImageProps`.

Let's try the other way around. Instead of deriving `AvatarImageProps` from `User`, we'll decouple them. We'll create a new type which just has the properties we need:

```tsx
type AvatarImageProps = {
  imageUrl: string;
  name: string;
};
```

Now, `AvatarImageProps` is decoupled from `User`. We can move `User` around, split it into separate interfaces, or even delete it, and `AvatarImageProps` will be unaffected.

In this particular case, decoupling feels like the right choice. This is because `User` and `AvatarImage` are separate concerns. `User` is a data type, while `AvatarImage` is a UI component. They have different responsibilities and different reasons to change. By decoupling them, `AvatarImage` becomes more portable and easier to maintain.

What can make decoupling a difficult decision is that deriving can make you feel 'clever'. `Pick` tempts us because it uses a more advanced feature of TypeScript, which makes us feel good for applying the knowledge we've gained. But often, it's smarter to do the simple thing, and keep your types decoupled.

### When Deriving Makes Sense

Deriving makes most sense when the code you're coupling shares a common concern. The examples in this chapter are good examples of this. Our `as const` object, for instance:

```typescript
const albumTypes = {
  CD: "cd",
  VINYL: "vinyl",
  DIGITAL: "digital",
} as const;

type AlbumType = (typeof albumTypes)[keyof typeof albumTypes];
```

Here, `AlbumType` is derived from `albumTypes`. If we were to decouple it, we'd have to maintain two closely related sources of truth:

```typescript
type AlbumType = "cd" | "vinyl" | "digital";
```

Because both `AlbumType` and `albumTypes` are closely related, deriving `AlbumType` from `albumTypes` makes sense.

Another example is when one type is directly related to another. For instance, our `User` type might have a `UserWithoutId` type derived from it:

```typescript
type User = {
  id: string;
  name: string;
  imageUrl: string;
  email: string;
};

type UserWithoutId = Omit<User, "id">;

const updateUser = (id: string, user: UserWithoutId) => {
  // ...
};
```

Again, these concerns are closely related. Decoupling them would make our code harder to maintain and introduce more busywork into our codebase.

The decision to derive or decouple is all about reducing your future workload.

Are the two types so related that updates to one will need to ripple to the other? Derive.

Are they so unrelated that coupling them could result in more work down the line? Decouple.


In this book teaser, we discuss deriving vs decoupling your types: when building relationships between your types or segregating them makes sense.

Deriving vs Decoupling: When NOT To Be A TypeScript Wizard

TypeScript 5.4 brought a new utility type called `NoInfer`. Let's see how it can be used to improve TypeScript's inference behavior in certain situations.

## What is `NoInfer`?

`NoInfer` is a utility type that can be used to prevent TypeScript from inferring a type from inside a generic function.

We'll look at _why_ you'd want to do this in a moment. But first, let's see it at work.

Imagine we have a generic function that just returns the type of the value passed in:

```ts twoslash
const returnWhatIPassedIn = <T>(value: T) => value;

const result = returnWhatIPassedIn("hello");
//    ^?
```

In this case, TypeScript infers the type of `result` to be `"hello"`.

But what if we were to wrap `value: T` with `NoInfer`?

```ts twoslash
type NoInfer<T> = [T][T extends any ? 0 : never];

// ---cut---

const returnWhatIPassedIn = <T>(value: NoInfer<T>) => value;

const result = returnWhatIPassedIn("hello");
//    ^?
```

`NoInfer` has prevented `value` from being a valid source of inference for `T`. So now, `result` is inferred as `unknown`. We'd need to explicitly provide the type to `returnWhatIPassedIn` to get the desired return type:

```ts twoslash
type NoInfer<T> = [T][T extends any ? 0 : never];

const returnWhatIPassedIn = <T>(value: NoInfer<T>) => value;

// ---cut---

const result = returnWhatIPassedIn<"hello">("hello");
//    ^?
```

So, why would you want to do this?

## The Problem `NoInfer` Solves

Let's imagine that you have a function that has multiple candidates for inferring a type parameter.

A great example is a function that creates a finite state machine (FSM). The FSM has an `initial` state and a list of `states`. The `initial` state must be one of the `states`.

Let's use `declare` to define the function signature (so I don't have to provide an implementation):

```ts twoslash
declare function createFSM<TState extends string>(config: {
  initial: TState;
  states: TState[];
}): TState;
```

Notice that there are two possible places where TypeScript could infer the type `TState` from: `initial` and `states`.

If we try to call it, TypeScript will infer `TState` from BOTH `initial` and `states`:

```ts twoslash
declare function createFSM<TState extends string>(config: {
  initial: TState;
  states: TState[];
}): TState;

// ---cut---

const example = createFSM({
  initial: "not-allowed",
  states: ["open", "closed"],
});

console.log(example);
//          ^?
```

But this is a problem! We want TypeScript to infer `TState` from `states` only. We don't want `initial` to be a candidate for inference. We want to ensure that `initial` is a valid state in the `states` array.

This is where `NoInfer` comes in.

## How `NoInfer` Helps

We can use `NoInfer` to prevent `initial` from being a candidate for inference:

```ts twoslash
type NoInfer<T> = [T][T extends any ? 0 : never];

// ---cut---

declare function createFSM<TState extends string>(config: {
  initial: NoInfer<TState>;
  states: TState[];
}): TState;
```

Now, when we call `createFSM`, TypeScript will infer `TState` from `states` only. This means that we correctly get an error from our `initial` property:

```ts twoslash
// @errors: 2322
type NoInfer<T> = [T][T extends any ? 0 : never];

declare function createFSM<TState extends string>(config: {
  initial: NoInfer<TState>;
  states: TState[];
}): TState;

// ---cut---

createFSM({
  initial: "not-allowed",
  states: ["open", "closed"],
});
```

If we swap `NoInfer` over to `states`, then the only valid `states` will be the value of `initial`:

```ts twoslash
// @errors: 2322
type NoInfer<T> = [T][T extends any ? 0 : never];

// ---cut---
declare function createFSM<TState extends string>(config: {
  initial: TState;
  states: NoInfer<TState>[];
}): TState;

createFSM({
  initial: "open",
  states: ["closed"],
});
```

So, we can use `NoInfer` to control where TypeScript infers a type from inside a generic function. This can be useful when you have multiple runtime parameters each referencing the same type parameter. `NoInfer` allows you to control which parameter TypeScript should infer the type from.


Learn how TypeScript's new utility type, NoInfer, can improve inference behavior by controlling where types are inferred in generic functions.