In TypeScript, if you try to assign to a property of a possibly undefined object, you'll get an error:

> 'X' is possibly undefined.

```ts twoslash
declare const obj: { foo?: string } | undefined;
// @errors: 18048

// ---cut---
obj.foo = "bar";
```

You might think that you can use the optional chaining syntax to fix this:

```ts twoslash
// @errors: 2779
declare const obj: { foo?: string } | undefined;

// ---cut---
obj?.foo = "bar";
```

But you end up with an error:

> The left-hand side of an assignment expression may not be an optional property access.

This is because optional chaining is only for reading properties (or deleting properties), not for assigning to them.

But today, the [optional chaining for assignments proposal](https://github.com/nicolo-ribaudo/proposal-optional-chaining-assignment) has landed in Stage 1 of TC39.

If this proposal gets adopted into JavaScript, the code below will no longer error.

```ts twoslash
// @errors: 2779
declare const obj: { foo?: string } | undefined;

// ---cut---
obj?.foo = "bar";
```


The optional chaining for assignments proposal has reached Stage 1, allowing assignment to possibly undefined object properties.

Optional Chaining for Assignments Lands in Stage 1

A common refrain in the web development discourse is that TypeScript is 'just a linter for JavaScript'. It's an oddly multifaceted phrase. It can be used to disdain TypeScript as a 'mere' linter, or to praise it for its simplicity.

I want to give this statement the attention it deserves. Is TypeScript just a linter? No, but yes.

## TypeScript Is Just JavaScript

TypeScript is the most successful attempt ever to create a meta-language for JavaScript. It's JavaScript's tastiest flavor. Milder than CoffeeScript. Sweeter than ClojureScript.

Part of its success is its fidelity to JavaScript. It clings tightly to it. Since enums, TypeScript has added zero new runtime features not already present in JavaScript. Its early attempts to add runtime features are now [falling out of fashion](/books/total-typescript-essentials/typescript-only-features#when-to-prefer-es-vs-ts). These days, TypeScript concerns itself with typing JavaScript.

TypeScript requires far fewer annotations than most typed languages. It can [infer](/books/total-typescript-essentials/essential-types-and-annotations#type-inference) a great deal just by looking at your code. So your JavaScript outputs often look identical to your TypeScript inputs, but with the types stripped out.

Unmask TypeScript, and you'll find JavaScript. The space between them is thin. This is a good thing.

I've been curious about the more refined flavors of JavaScript for a while now. [Elm](https://elm-lang.org/) and [ReScript](https://rescript-lang.org/) especially. But betting company code on these languages feels risky. There are a lot more JavaScript developers than Elm developers. And TypeScript is just a linter for JavaScript.

## Is TypeScript "Strongly Typed"?

But TypeScript is not just a linter for JavaScript. According to its own [landing page](https://www.typescriptlang.org/), it is a 'strongly typed programming language'. This assertion feels controversial, and I've seen 'TypeScript is a linter' used in rebuttal. "TypeScript is just JavaScript with some types added, not a language by itself".

TypeScript certainly has some types. Basic types. Object types. Types for the DOM. But there's one type that calls the rest into question: [`any`](https://www.totaltypescript.com/books/total-typescript-essentials/essential-types-and-annotations#the-any-type).

`any` breaks the rules. It's a nuclear warhead against rock, paper, scissors. It can infect a codebase, metastasizing from a single function. Its mere presence in the language means, in my eyes, TypeScript cannot be considered 'strongly typed'. There are no guarantees. The center cannot hold.

`any` has to exist. If it didn't, TypeScript would be burdened with the challenge of describing the entirety of JavaScript in types. `any` is a pressure valve. It makes TypeScript simpler and leaner. I'm glad it exists.

But `any` is a virus that remakes its host. TypeScript's types are at best advisory. Guidelines, not rules. You can disable its checking at any time. TypeScript is just a linter for JavaScript.

## TypeScript Is Just A Linter

Let's state the obvious. TypeScript is not just a linter. It's an astonishingly advanced type system. It's a compiler. It's a language server that can run on any compatible IDE.

But thinking of it _like_ a linter is useful. Its type system lives to serve JavaScript. It's easy to adopt. It's easy to eject from. If you don't understand it, shut it up and move on.

And embrace it. You're not a TypeScript dev. You're a JavaScript dev. `typeof NaN` is a number and `typeof null` is an object. You'll get more out of TypeScript as a result.


Is TypeScript just a linter? No, but yes.

Is TypeScript Just A Linter?

Today is the biggest ship day of my life. After 11 months of work, I'm launching:

- Total TypeScript Essentials: a 16-chapter [TypeScript book](https://www.totaltypescript.com/books/total-typescript-essentials), for FREE.
- [Pro Essentials](https://www.totaltypescript.com/workshops/typescript-pro-essentials): a new, 200-exercise course for $200.
- A giveaway worth ~$80,000 to existing customers.
- A huge price cut on Total TypeScript.
- A 20% sale until Friday.

Here's the full story:

## The Book - Total TypeScript: Essentials

My book, [Total TypeScript: Essentials](https://www.totaltypescript.com/books/total-typescript-essentials), is finally ready.

It's been 11 months of work. 16 chapters. Hundreds of pages. And it's free.

It covers everything you need to get a job with TypeScript, from setting up your IDE to understanding generics.

And it's 100% freely available on Total TypeScript. Forever.

We'll also be releasing this as a printed book! You can pre-order a copy on [No Starch's site](https://nostarch.com/total-typescript).

## The Course - Pro Essentials

We're also releasing a new course, [Pro Essentials](https://www.totaltypescript.com/workshops/typescript-pro-essentials).

It's the ultimate TypeScript masterclass - the no-brainer training programme to help your team build TypeScript apps.

It contains over 200 exercises and requires no TypeScript experience.

And, until Friday, it's $200.

Pro Essentials is different from everything else I've shipped.

Before, I focused on advanced content to turn you into a TS wizard. The content in the [Core Volume](https://www.totaltypescript.com/workshops) is perfect for this.

But with Essentials (the book) and Pro Essentials (the course), I want Total TypeScript to be the default choice for teams.

Got a team transitioning to TS? Get them Pro Essentials, at $200 a pop (cheaper in bulk) and you'll have some happy engineers working at max capacity.

## Price Cut and Giveaway

We've slashed the price of Total TypeScript. You can now pick up the entire of TT, including Pro Essentials, for $500.

And until Friday, it's 20% off: $400.

This is a HUGE drop from where it was before.

What about the folks that already paid the higher price for the existing workshops?

Existing TT customers will get Pro Essentials for free. Over all our customers, that's around $80,000 of giveaway.

I'm so excited to finally share this with you. I hope you enjoy it as much as I enjoyed creating it.


It's a massive ship day. We're launching a free TypeScript book, new course, giveaway, price cut, and sale.

Announcing: A Free Book, A New Course, A Huge Price Cut...

Sometimes, the way you order your object properties matters.

## The Setup

Let's imagine we create a function that takes in an object as its argument. In this object, there are two properties: `produce` and `consume`.

```ts twoslash
const process = <T>(obj: {
  produce: (input: string) => T;
  consume: (t: T) => void;
}) => {
  const value = obj.produce("abc");
  obj.consume(value);
};

// ---cut---

process({
  produce: (input) => Number(input),
  consume: (output) => console.log(output),
  //                               ^?
});
```

`produce` takes in an input of `string` and returns some type. `consume` then takes in that value and does something with it. Because of a clever type definition, TypeScript can infer the type of the value returned by `produce` and pass it to `consume`:

```ts twoslash
const process = <T>(obj: {
  produce: (input: string) => T;
  consume: (t: T) => void;
}) => {
  const value = obj.produce("abc");
  obj.consume(value);
};
```

We can use this setup with any type of value, and it'll just work:

```ts twoslash
const process = <T>(obj: {
  produce: (input: string) => T;
  consume: (t: T) => void;
}) => {
  const value = obj.produce("abc");
  obj.consume(value);
};

// ---cut---
process({
  produce: (input) => input + "hello",
  consume: (output) => console.log(output),
  //                               ^?
});

process({
  produce: (input) => ({ value: input }),
  consume: (output) => console.log(output),
  //                               ^?
});
```

## The Problem

This all looks great, until one of our users complains to us. They're trying to use our function, but it's not working:

```ts twoslash
const process = <T>(obj: {
  produce: (input: string) => T;
  consume: (t: T) => void;
}) => {
  const value = obj.produce("abc");
  obj.consume(value);
};

// ---cut---

process({
  consume: (output) => console.log(output),
  //                               ^?
  produce: (input) => Number(input),
});
```

The `output` is being seen by TypeScript as `unknown`. This feels very odd, as the `produce` function is clearly returning a `number`. What's going on?

The difference here is that the user specified `consume` _before_ `produce`. Since TypeScript 4.7, in [this PR](https://github.com/microsoft/TypeScript/pull/48538), TypeScript now uses the order of properties to inform its inference. This was added to fix various long-standing bugs (linked in the PR) with context-sensitive functions.

This means that, in some very narrow cases, the order you specify your properties matters. So if you're running up against strange errors to do with property ordering, that's why!

## Could You Use `NoInfer`?

You might be wondering if you could use [`NoInfer`](https://www.totaltypescript.com/noinfer) to fix this. That seems sensible, given that `NoInfer` is used to force TypeScript to avoid inference on certain targets.

However, it doesn't:

```ts twoslash
const process = <T>(obj: {
  produce: (input: string) => T;
  consume: NoInfer<(t: T) => void>;
}) => {
  const value = obj.produce("abc");
  obj.consume(value);
};

process({
  consume: (output) => console.log(output),
  //                               ^?
  produce: (input) => Number(input),
});
```

The result is still `unknown`. How frustrating!


Learn why the order you specify object properties in TypeScript matters and how it can affect type inference in your functions.

Sometimes, Object Property Order Matters

I've just learned about `corepack`, a tool that bundles with Node.js and solves a bunch of problems with handling package managers. But I'll be using it in my development setup from now on.

## Quick Start

### Step 1. Global Install

`corepack` is bundled with Node.js, and has been since Node.js 14.19. So, if you have Node.js, you have `corepack`.

You can enable `corepack` on your machine by running the following command:

```bash
corepack enable && corepack enable npm
```

This enables `corepack` globally - you don't need to enable it per project.

### Step 2. Configure Your Project

`corepack` makes sure you're using the correct package manager for your project. To configure the package manager for your project, add the `packageManager` field to your `package.json`:

```json
{
  // npm
  "packageManager": "npm@10.8.1",
  // pnpm
  "packageManager": "pnpm@9.1.4",
  // yarn
  "packageManager": "yarn@3.1.1"
}
```

You must specify an _exact_ version of the package manager you want to use - not a range. All of the below are not valid:

```json
{
  // not valid: uses a range
  "packageManager": "npm@^10.8.1",

  // not valid: specifies 'latest'
  "packageManager": "pnpm@latest",

  // not valid: must specify an exact version
  "packageManager": "yarn"
}
```

### Step 3. Try It Out

Now, if you try to `npm install` in a project that has `packageManager` set to `pnpm`, `corepack` will show an error:

```txt
Usage Error: This project is configured to use pnpm

$ npm ...
```

And if you try to `pnpm install` there, `corepack` will automatically download and use the correct `pnpm` version:

```txt
Corepack is about to download https://registry.npmjs.org/pnpm/-/pnpm-9.1.4.tgz.

Do you want to continue? [Y/n]
```

This ensures you're always using the correct package manager for your project.

## Why Do We Need `corepack enable npm`?

`corepack` intercepts calls to `pnpm` and `yarn` to make sure you're using them correctly. This is set up by running `corepack enable`.

Without running `corepack enable npm`, you won't get the same validation when using `npm`. So, we run `corepack enable npm` to make sure that `npm` gets treated the same way as `pnpm` and `yarn`.

## Why Use Corepack?

I ran out of time to continue writing this article. Want me to keep going? What questions do you have? Let me know:

<FeedbackFormButton />


Learn how to use `corepack` to configure package managers in Node.js projects, ensuring you always use the correct one.

How To Use Corepack

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.